[Bug 668707] New: mpegtsdemux: Seeking of some content can cause playback to stop (buffer without new-segment reaches video sink)
bugzilla at gnome.org
Wed Jan 25 19:25:06 PST 2012
GStreamer | gst-plugins-bad | 0.10.x
Summary: mpegtsdemux: Seeking of some content can cause
playback to stop (buffer without new-segment reaches
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
Internal data flow problem.
Additional debug info:
gstbasesink.c(3638): gst_base_sink_chain_unlocked ():
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
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.
More information about the gstreamer-bugs