GNOME Bugzilla – Bug 668707
mpegtsdemux: Seeking of some content can cause playback to stop (buffer without new-segment reaches video sink)
Last modified: 2013-06-12 06:16:53 UTC
In a private sample I can very reliably and very often cause playback to stop on the 0.10 branch and git master when seeking around with navseek. Once it stops, the video holds still, audio buffer could drain empty (so there's sound for a while), and then it just sits there. To get out of the state, issuing another seek with the arrow keys can get it out of there. When it happens, the following is printed on the terminal: WARNING: from element /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstBin:bin0/GstXvImageSink:xvimagesink0: Internal data flow problem. Additional debug info: gstbasesink.c(3638): gst_base_sink_chain_unlocked (): /GstPlayBin2:playbin20/GstPlaySink:playsink0/GstBin:vbin/GstBin:bin0/GstXvImageSink:xvimagesink0: Received buffer without a new-segment. Assuming timestamps start from 0. Presumably video sink gets thoroughly confused about timestamps and the pipeline can't really play anything. But with GST_DEBUG=mpegtsdemux:3 something like this does come right before the data flow error: 0:01:12.989121044 17160 0xd564c0 INFO mpegtsdemux gstmpegtsdemux.c:2927:gst_mpegts_demux_sink_event:<d> received new segment: rate 1 format 2, start: 54277849, stop: 388052680, time: 54277849 (verified by manually making sure I know it was from the seek event I issued that caused the problem; multiple times). With a manual pipeline I can't seem to get out of the dead state with another seek for some reason, while I can with playbin2. I was able to reproduce it with http://samples.mplayerhq.hu/V-codecs/h264/cathedral-beta2-400extra-crop-avc.mp4 as well, but it is much much MUCH harder with that sample. But that's demuxed with qtdemux instead... So not sure it's exactly mpegtsdemux. I have never been able to reproduce this problem with the latest stable release versions (i.e, what I have from my distribution). Suspicion was on h264parse (or aacparse) being plugged now, but I can reproduce it on 0.10 also with a fully manual pipeline that doesn't have the parsers. I can reproduce this with tsdemux on 0.10 branch as well. With tsdemux seeking is of course even more problematic right now; more freezes also without the new-segment message, and so on. Seeking in general "feels" really iffy, but that is the case with latest releases as well, but there it "feels" less iffy.
Maybe related to the following? https://bugzilla.gnome.org/show_bug.cgi?id=670080 Just a guess, as this sound similar to what we saw under some conditions on recorded live streams from a users point of view. You could try with the patch attached there (or flutsdemux).
Closing bug, 0.10 is dead. Seeking is fixed in 1.x