GNOME Bugzilla – Bug 138666
[playbin] cannot handle files with large initial delay in one stream
Last modified: 2005-01-27 13:57:16 UTC
gst-player --gst-basicgthread _bad_/div3/lego_troopers_divx.avi console : ERROR GST_PADS(13951) gstpad.c(3105):gst_pad_pull:<src_0> (null) ERROR GST_PADS(13951) gstpad.c(3105):gst_pad_pull:<src_0> pull on pad src_0:sink but the peer pad avidemux0:audio_00 has no gethandler file says : lego_troopers_divx.avi: RIFF (little-endian) data, AVI, 368 x 276, 10.00 fps, video: DivX 3 Low-Motion, audio: uncompressed PCM (mono, 22050 Hz) mplayer says : VIDEO: [DIV3] 368x276 24bpp 10,000 fps 30,2 kbps ( 3,7 kbyte/s) ========================================================================== Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 22050 Hz, 1 ch, 8 bit (0x8), ratio: 22050->22050 (176,4 kbit) Selected audio codec: [pcm] afm:pcm (Uncompressed PCM) ========================================================================== ========================================================================== Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family Selected video codec: [ffdivx] vfm:ffmpeg (FFmpeg DivX ;-) (MS MPEG-4 v3)) ========================================================================== Checking audio filter chain for 22050Hz/1ch/8bit -> 22050Hz/2ch/8bit... AF_pre: af format: 1 bps, 1 ch, 22050 hz, little endian unsigned int AF_pre: 22050Hz 1ch Unsigned 8-bit AO: [oss] 22050Hz 2ch Unsigned 8-bit (1 bps) Building audio filter chain for 22050Hz/1ch/8bit -> 22050Hz/2ch/8bit...
gst-player --gst-scheduler=basicgthread 2_sado\ maso\ breast\ piercing\ sick.avi does the same error : ERROR GST_PADS(15098) gstpad.c(3105):gst_pad_pull:<src_0> (null) ERROR GST_PADS(15098) gstpad.c(3105):gst_pad_pull:<src_0> pull on pad src_0:sink but the peer pad avidemux0:audio_00 has no gethandler this one is a iv32/uncompressed PCM 2_sado maso breast piercing sick.avi: RIFF (little-endian) data, AVI, 240 x 180, 12.00 fps, video: Indeo 3.2, audio: uncompressed PCM (mono, 11025 Hz) the common point between those 2 is the audio stream format mplayer says this on the audio part : Opening audio decoder: [pcm] Uncompressed PCM audio decoder AUDIO: 11025 Hz, 1 ch, 8 bit (0x8), ratio: 11025->11025 (88,2 kbit) Selected audio codec: [pcm] afm:pcm (Uncompressed PCM)
same thing for _bad_/iv32/quelle.avi : quelle.avi: RIFF (little-endian) data, AVI, 240 x 180, ~15 fps, video: Indeo 3.2, audio: uncompressed PCM (mono, 22050 Hz) ERROR GST_PADS(15202) gstpad.c(3105):gst_pad_pull:<src_0> (null) ERROR GST_PADS(15202) gstpad.c(3105):gst_pad_pull:<src_0> pull on pad src_0:sink but the peer pad avidemux0:audio_00 has no gethandler ------------------------------------------ _bad_/iv32/sado-maso\ \(piss\).mpg (which is an avi) _bad_/iv50/chienne_de_maria...avi _bad_/iv50/Q_The_White_Stripes...avi
_bad_/mp42/Sado\ Maso\ Porno\ -\ porn\ sex\ sm\ slave\ \(2mins\)*.avi _bad_/_rgb/DIB_showattachment.avi
ERROR GST_PADS(25281) gstpad.c(3105):gst_pad_pull:<src_0> (null) ERROR GST_PADS(25281) gstpad.c(3105):gst_pad_pull:<src_0> pull on pad src_0:sink but the peer pad qtdemux0:audio_00 has no gethandler it's with the file that Uraeus tested in http://bugzilla.gnome.org/show_bug.cgi?id=138321
I see the same bug. Interestingly, other schedulers work fine here, which makes me believe it's a scheduler bug in basic (yay! even basic is imperfect). Entry plays it fine. The lego_troopers avi plays fine, but with hickups. Xine has similar hickups, but less severe. This might be related to the large chunks that the file contains (audio). I don't know how to fix that as of now.
Benjamin committed a fix to basic to make this work. Plays fine now, still has stuttering playback. Changing topic to reflect new bug.
I just looked at this again, and the issue really is that timestamps are so far apart. When the audio is at 55s, the video is still around 46s. So there may be some A/V sync issue in this file or whatsoever. mplayer works around it by not using the scale/rate of files with such headers. Instead, they divide the total length of the audio stream (bytes) by the length of the video stream (time) and use that as av_bps value for timestamp calculation. Might be interesting to use for us as well, although I'm not convinced that it's correct.
Ok, so current CVS of $today plays this almost correctly. There's one small item remaining: dynamic queue resizing in your media player. The audio starts at 8s, and our queue is 1s (or 3s in playbin), so it hangs. Apart from that, if you manually resize queues, it plays perfectly.
Gst-player is no longer maintained, and have been deprecated in favour of Totem. gst-player will tommorow be removed from bugzilla. Closing as wontfix.
Dude, this is a playbin bug.
Hm, my initial comment is wrong, init_delay isn't large at all. A/V sync is good, it's just a bit choppy. From what I can see, this is just the movie, it repeats frames quite a lot. Therefore, I no longer think this needs further fixing - marking fixed.