GNOME Bugzilla – Bug 628322
problem by playing chained video ogg file
Last modified: 2012-09-20 17:00:41 UTC
Created attachment 169054 [details] chained video Hallo, i have problems to play chained video ogg. First part played smoothly, the second with pauses on video. to reproduce i used ffmpeg2theora -p preview -s 2500 -e 2510 -o foo.ogg samplevideo.ogg ffmpeg2theora -p preview -s 2550 -e 2560 -o foo2.ogg samplevideo.ogg cat foo2.ogg >> foo.ogg
<hadess> __tim: can you reproduce https://bugzilla.gnome.org/show_bug.cgi?id=628322 ? <__tim> hadess, maybe: with git it plays fine for me, both from local file and http, while with core/base 0.10.30 it just seems to stop after the first chain <__tim> where stop=eos <hadess> __tim: i'll reassign and somebody will probably find the dupe then :)
Thank you :D
This patch should fix the EOS issue, although the video seems to freeze after it switches to a different chain, it might be a new-segment issue or something like that. If you seek though (used totem) it will play fine instead of stopping. http://cgit.collabora.com/git/user/kakaroto/gst-plugins-base.git/commit/?id=26155822adf734af16634a99effc3aca0989a4ef
Only just realized I pushed something similar this morning. Haven't investigated the timing issue though. commit c91928f7a2461aba57f64e014f507bcb62d7adc6 Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Jul 25 10:41:04 2011 +0200 decodebin2: Properly handle multi-stream chains When we have a multi-stream (i.e. audio and video) input and the demuxer adds/removes pads for a new stream (common in a mpeg-ts stream when the program stream mapping is updated), the algorithm for EOS handling was previously wrong (it would only drop the EOS of the *last* pad but would let the EOS on the other pads go through). The logic has only been changed a tiny bit for EOS handling resulting in: * If there is no next group, let the EOS go through * If there is a next group, but not all pads are drained in the active group, drop the EOS event * If there is a next group and all pads are drained, then the ghostpads will be removed and the EOS event will be dropped automatically.
This is caused by the second chain causing a second Theora decoder to be created, and being unaware of the running time of the first chain. The second decoder then receives buffers from timestamp 0 in the new segment, and sees the associated running time as starting from 0. However, it also receives QoS messages with timestamps taking that previous running time into account, and thus believes it is very late, and drops all frames. A fix would need to reconcile the two time bases by making the second decoder aware of the running time of the previous chain's decoder, but I don't see a clean way to do that at the moment. A workaround is to disable QoS for the Theora decoder, and playback works as expected. Note that the Vorbis decoder does not do QoS, which is why audio works fine here.
This should be fixed when enabling the stream synchronizer in playsink, at least it worked last time I enabled it.
All the while debugging this, I had this horrible feeling of deja vu without being able to remember, and that comment just brought it all back. I had already debugged that issue, and found that enabling that made it work. Sigh. Yep, setting passthrough to FALSE makes it work too.
Only problem is that enabling the streamsynchronizer causes playback issues in other situations. We should make sure that this is fixed in 0.11 as it might require core changes
This seems to work now in 0.11 / git master, closing.