bugGnash - The GNU Flash player - Bugs: bug #31806, MediaParserFfmpeg fails playing...

 
 

bug #31806: MediaParserFfmpeg fails playing short youtube MPEG-4 contained video

Submitter:  Sandro Santilli <strk>
Submitted:  Mon 06 Dec 2010 07:54:47 AM UTC
   
 
Category:  video-ffmpeg Severity:  5 - Blocker
Release:  master Status:  Fixed
Privacy:  Public Assigned to:  bjacques
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 09 Mar 2011 05:26:51 PM UTC, comment #20: 

Ok, tried with Gnash 0.8.9dev (master-19988-c0e405e) and indeed works. Then I guess I'll file a new one for the crash, if no existing one is appropriate.

Sandro Santilli <strk>
Group Member
Wed 09 Mar 2011 04:36:34 PM UTC, comment #19: 

Ok, I'll try asap.
For now I confirm that master-19874-1f82c61 gives me never-ending circle widget.

Sandro Santilli <strk>
Group Member
Wed 09 Mar 2011 12:51:29 PM UTC, comment #18: 

I attempted to fix playback of the youtube movie provided in the original submission: http://www.youtube.com/v/le9kYqIAtjY .

Bastiaan Jacques <bjacques>
Group Member
Wed 09 Mar 2011 08:13:08 AM UTC, comment #17: 

Please link to commit when setting ready-for-test state.
I'm guessing this was for commit 7a110fe81c2d181d247736e19e80750449f0f622

The change doesn't fix my experience of playing the snow.mpg file.
Visible effects are a_bunch of these:


30579:2] 08:15:47 ERROR: MediaParserFfmpeg couldn't parse input format: tried to seek at negative offset -9223372036854305385.
30579:2] 08:15:47 ERROR: MediaParserFfmpeg couldn't parse input format: tried to seek at negative offset -9223372036854305419.
30579:2] 08:15:47 ERROR: MediaParserFfmpeg couldn't parse input format: tried to seek at negative offset -9223372036854305453.
30579:2] 08:15:47 ERROR: MediaParserFfmpeg couldn't parse input format: tried to seek at negative offset -9223372036854305487.

And a final crash:


Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7d51b70 (LWP 30798)]
0x0012d422 in __kernel_vsyscall ()
(gdb) bt
#0  0x0012d422 in __kernel_vsyscall ()
#1  0x0138d651 in *__GI_raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2  0x01390a82 in *__GI_abort () at abort.c:92
#3  0x01386718 in *__GI___assert_fail (
    assertion=0xa675d6 "std::ftell(_data) == pos",
    file=0xa70dfc "../../gnash-git/libbase/tu_file.cpp", line=182,
    function=0xa716a0 "virtual bool gnash::tu_file::seek(std::streampos)")
    at assert.c:81
#4  0x00a4171b in gnash::tu_file::seek (this=0x8269d30, pos=...)
    at ../../gnash-git/libbase/tu_file.cpp:182
#5  0x009b672b in gnash::media::ffmpeg::MediaParserFfmpeg::seekMedia (
    this=0x8209800, offset=4294998094, whence=0)
    at ../../gnash-git/libmedia/ffmpeg/MediaParserFfmpeg.cpp:551

The above is with local (no network) load of the file (trough easyvideo.swf). FFmpeg is 4:0.5.1-1ubuntu1.

The bug was hijacked so not sure if I should change the summary back to original or not... anyway the original bug isn't fixed yet.

Sandro Santilli <strk>
Group Member
Sun 27 Feb 2011 07:52:25 PM UTC, comment #16: 

< bjacques> strk: -32 == EOF

Now I get it. Bastiaan thinkgs that ERROR isn't really a big deal, and all might still work if we just gave it a chance to.

Not that this explains why the circle keeps spinning rather
than giving the "video is finished" screen.

Sandro Santilli <strk>
Group Member
Sun 27 Feb 2011 07:50:46 PM UTC, comment #15: 

Oops, sorry, it was:

ERROR: MediaParserFfmpeg::parseNextFrame: Problems parsing next frame (av_read_frame returned -32). We'll consider the stream fully parsed.

Sandro Santilli <strk>
Group Member
Sun 27 Feb 2011 07:49:17 PM UTC, comment #14: 

I kind of feel this bug was hijacked.
My original submission was about a parsing error with ffmpeg.
I still get it, with this message:

 ERROR: MediaParserFfmpeg fails parsing youtube video (mov,mp4,m4a,3gp,3g2,mj2)

The other issue is about playback. Shouldn't it be in a separate ticket ?

Sandro Santilli <strk>
Group Member
Thu 24 Feb 2011 08:51:44 AM UTC, comment #13: 

^both^all ?

I'm more concerned about the fact that we are guessing how big the audio device buffer is.

On this estimate we base our "finished" concept, as we take
transit from our own (MediaParser) buffers to an external one
as the sign of completed deliverable.

For video this is actually kind of better, IIRC.

Sandro Santilli <strk>
Group Member
Thu 24 Feb 2011 08:46:02 AM UTC, comment #12: 

Right, assuming there are two streams in the video.

Bastiaan Jacques <bjacques>
Group Member
Thu 24 Feb 2011 07:37:47 AM UTC, comment #11: 

I guess we should call it "finished" only when both streams are ?

Sandro Santilli <strk>
Group Member
Thu 24 Feb 2011 02:31:36 AM UTC, comment #10: 

By the way, the error message about failure to parse is nothing more than the parser reaching EOF.

Bastiaan Jacques <bjacques>
Group Member
Thu 24 Feb 2011 02:28:48 AM UTC, comment #9: 

The bug is in Netstream_as.cpp. decodingStatus() controls whether all frames have been decoded and therefore the movie has finished playing. There is logic that decides decoding is finished when all the audio frames are decoded, but there also is logic deciding that it's finished when all the video frames are decoded.

In this particular instance (I'm not sure why) all of the audio finishes decoding after only one frame of video has been decoded. So, having decoded all the audio, NetStream_as calls it quits and claims it's finished everything.

I'm not entirely sure why this doesn't happen with Gstreamer; it may be that the timestamps provided are different.

Bastiaan Jacques <bjacques>
Group Member
Mon 20 Dec 2010 09:43:18 PM UTC, comment #8: 

in my case with ffmpeg doesn't play at all, just the image who show with the play button, then it keeps loading...

GST works great... no problem with it, just some errors:
ERROR: MediaParserGst failed to push more data into the demuxer! Seeking back.

-X- <maximi89>
Sun 12 Dec 2010 07:50:49 PM UTC, comment #7: 

I tested on my Lenny machine, and the video played just fine using

  gnash -M ffmpeg -vvv http://www.youtube.com/v/le9kYqIAtjY

I was told by Sandro Santilli on IRC that the crash is happening in libavformat52 and my version of this library is 3:20080706-0.3lenny2.

Petter Reinholdtsen <pere>
Group Member
Mon 06 Dec 2010 08:02:40 PM UTC, comment #6: 

Even ffmpeg svn from 2008-10 successfully plays that file

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 08:01:10 PM UTC, comment #5: 

Just tried ffplay linked against the same libraries, and it works fine. So must be our use of those libraries.

I've found that raising MediaParserFfmpeg::byteIOBufferSize from 1024 to 65535 prevents the bogus ::seek call (but still doesn't successfully play the stream)

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 10:12:16 AM UTC, comment #4: 

For completeness... ffmpeg codec ids correspond to these names:
 DEBUG: VideoDecoder: initialized FFMPEG codec h264 (28)

Never gets to initialize audio decoders..

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 09:50:45 AM UTC, comment #3: 

Note that GSTreamer handler has no problem with this.

Info about format:
GST finds:
 DEBUG: MediaParserGst/typefound: Detected media type audio/x-m4a
 DEBUG: MediaParserGst/typefound: Detected media type video/x-h264, codec_data=(buffer)01420015fde1000f67420015bb40f05bf260203c2010a801000568ce050ac8, width=(int)480, height=(int)346, framerate=(fraction)15/1
 DEBUG: MediaParserGst: Linked video source (type: video/x-h264)


FFMPEG finds:
 DEBUG: Parsing FFMPEG media file: format:mov,mp4,m4a,3gp,3g2,mj2; nstreams:2
 DEBUG:   Using stream 0 for audio: codec id 86018
 DEBUG:   Using stream 1 for video: codec id 28

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 09:32:28 AM UTC, comment #2: 

Uhm... doesn't seem to be a cast related thing:
31566:5] 10:30:44 ERROR: Offset: -9223372036854299469
31566:5] 10:30:44 ERROR: Offset (cast to std::streampos): -9223372036854299469

The number doesn't change

 libavformat52 4:0.5.1-1ubuntu1

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 09:21:18 AM UTC, comment #1: 

FFMPEG uses boost::int64 for positions
(also base MediaParser actually),
IOChannel uses std::streampos.

Dunno if this is related.
In this case FFMPEG is requesting a seek to absolute
position -9223372036854299469 (intepreted as a std::streampos)

Sandro Santilli <strk>
Group Member
Mon 06 Dec 2010 07:54:47 AM UTC, original submission:  

gnash -vvv http://www.youtube.com/v/le9kYqIAtjY

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe156a710 (LWP 27465)]
0x00007ffff4397a75 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) bt
#0  0x00007ffff4397a75 in *__GI_raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff439b5c0 in *__GI_abort () at abort.c:92
#2  0x00007ffff4390941 in *__GI___assert_fail (
    assertion=0x7ffff67299df "pos >= 0", file=<value optimized out>,
    line=1127,
    function=0x7ffff6727680 "virtual bool gnash::<unnamed>::CurlStreamFile::seek(std::streampos)") at assert.c:81
#3  0x00007ffff670082a in seek (this=0x13565c0, pos=...)
    at /usr/src/gnash/gnash-head/libbase/curl_adapter.cpp:1127
#4  0x00007ffff699fd0f in gnash::media::ffmpeg::MediaParserFfmpeg::seekMedia (
    this=0x121b370, offset=-9223372036854299469, whence=0)
    at /usr/src/gnash/gnash-head/libmedia/ffmpeg/MediaParserFfmpeg.cpp:536
#5  0x00007ffff025ea8c in url_fseek () from /usr/lib/libavformat.so.52
#6  0x00007ffff028c5cc in ?? () from /usr/lib/libavformat.so.52
#7  0x00007ffff028c7b3 in ?? () from /usr/lib/libavformat.so.52
#8  0x00007ffff025aa6e in av_read_packet () from /usr/lib/libavformat.so.52
#9  0x00007ffff025bad3 in ?? () from /usr/lib/libavformat.so.52
#10 0x00007ffff699f7b5 in gnash::media::ffmpeg::MediaParserFfmpeg::parseNextFrame (this=0x121b370)
    at /usr/src/gnash/gnash-head/libmedia/ffmpeg/MediaParserFfmpeg.cpp:252
#11 0x00007ffff6973c86 in gnash::media::MediaParser::parserLoop (
    this=0x121b370) at /usr/src/gnash/gnash-head/libmedia/MediaParser.cpp:413

Sandro Santilli <strk>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #22137:  snow.mpg added by strk (465KiB - application/octet-stream - the media file)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bjacques (Posted a comment)
  • -email is unavailable- added by maximi89 (Posted a comment)
  • -email is unavailable- added by pere (Posted a comment)
  • -email is unavailable- added by strk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-03-09 strk StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2011-03-09 strk StatusReady For Test Confirmed
    2011-03-09 bjacques Assigned toNone bjacques
    2011-03-09 bjacques StatusConfirmed Ready For Test
    2011-02-24 bjacques SummaryMediaParserFfmpeg fails parsing youtube video (mov,mp4,m4a,3gp,3g2,mj2) MediaParserFfmpeg fails playing short youtube MPEG-4 contained video
    2011-02-24 bjacques StatusNone Confirmed
    2010-12-06 strk Attached File- Added snow.mpg, #22137
    2010-12-06 strk Summaryassertion failure on youtube (ffmpeg media parser seek) MediaParserFfmpeg fails parsing youtube video (mov,mp4,m4a,3gp,3g2,mj2)
    2010-12-06 strk Severity3 - Normal 5 - Blocker
        ReleaseNone master

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code