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

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.

Oops, sorry, it was:

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

^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.

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

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.

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.

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)

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

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)