[Bug 668707] New: mpegtsdemux: Seeking of some content can cause playback to stop (buffer without new-segment reaches video sink)

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=668707
  GStreamer | gst-plugins-bad | 0.10.x

           Summary: mpegtsdemux: Seeking of some content can cause
                    playback to stop (buffer without new-segment reaches
                    video sink)
    Classification: Platform
           Product: GStreamer
           Version: 0.10.x
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: leio at gentoo.org
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.