GNOME Bugzilla – Bug 595161
[mpegtsdemux] Internal dataflow problem with some streams.
Last modified: 2009-10-29 19:45:32 UTC
Overview: I'm having problems with playing some mpeg streams from dvb card. From time to time (1/10 of times) when i start watching some channel, it is stuck at the first frame (sometimes audio is playing, though). Here's error message: (gst-launch-0.10:1975): GStreamer-CRITICAL **: gst_event_new_new_segment_full: assertion `start != -1' failed (gst-launch-0.10:1975): GStreamer-CRITICAL **: gst_pad_push_event: assertion `event != NULL' failed WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Internal data flow problem. Additional debug info: gstbasesink.c(3283): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: Received buffer without a new-segment. Assuming timestamps start from 0. Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock I did record some very short samples of this TS files and they can be played without problems on mplayer and VLC but not with gstreamer. Steps to reproduce: - Take one of my failing samples from http://box1.japko.eu/mpegtsdemuxbug/fail/ - Play it with gstreamer using one of following pipelines: * gst-launch playbin uri=file:///fail/sample.9.ts * gst-launch filesrc location=/fail/sample.9.ts ! mpegtsdemux ! mpeg2dec ! ffmpegcolorspace ! xvimagesink Actual Results: The file is not played. It stops at the first frame. Expected Results: File being played without problems. Build Date & Platform: The problem seams to occur in all versions of mpegtsdemux in gstreamer-plugin-bad. I'm testing this on Ubuntu system (both with it's default packages and my own packages build from newest versions). Additional Information: - There are couple failing samples here: http://box1.japko.eu/mpegtsdemux/fail/ - You can compare them with working samples from: http://box1.japko.eu/mpegtsdemux/ok/ - debug log attached
Debug log was to big to attach it here. It's on: http://box1.japko.eu/mpegtsdemux/log.txt
I have compared two streams (failing one and good one) and it seams they differ in that failing stream does not provide PTS: DEBUG mpegpesfilter gstpesfilter.c:298:gst_pes_filter_parse: header_data_length: 0, flags 0x00 which means it's value is set to -1: DEBUG mpegtsdemux gstmpegtsdemux.c:1024:gst_mpegts_demux_data_cb:<mpegtsdemux0> setting PTS to (18446744073709551615) time: 99:99:99.999999999 on buffer 0xb6502df0 first buffer: 1 base_time: 0:00:00.000000000 Since no base PCR or last PCR is set: DEBUG mpegtsdemux gstmpegtsdemux.c:769:gst_mpegts_demux_send_new_segment:<mpegtsdemux0> no base PCR, using last PCR 18446744073709551615 DEBUG mpegtsdemux gstmpegtsdemux.c:776:gst_mpegts_demux_send_new_segment:<mpegtsdemux0> no last PCR, using PTS 18446744073709551615 Time is set to -1: DEBUG mpegtsdemux gstmpegtsdemux.c:785:gst_mpegts_demux_send_new_segment:<mpegtsdemux0> segment PTS to (18446744073709551615) time: 18446744073709551615 and it is then passed to gst_event_new_new_segment, which causes assertion fail: GStreamer-CRITICAL **: gst_event_new_new_segment_full: assertion `start != -1' failed The problem is, I don't know what should be done in such case since I'm not MPEG expert so I can't fix it myself.
sample.9.ts works fine for me with latest GIT of gst-plugins-bad. Can you confirm that it's fixed for you too?
For the other files (I tested 16 and 20) it still hangs at the first frame and prints the assertion failures.
Strange. Nothing changed after updating gst-plugins-bad to git version. sample.9.ts still hangs at the first frame.
Created attachment 146379 [details] [review] mpegtsdemux: Don't send new-segment with start time == -1 When sending new-segment to a stream, ensure that there is either a valid PCR, or else wait until there's a PTS on the stream (dropping packets if needed) in order to avoid generating an invlaid new-segments event.
This patch makes it work for me...
Works for me too.
It fixes the problem for me. Thank you.
Please let maintainers/developers close bugs. In this case the patch still hasn't been pushed. Jan, will you do the honors ?
I wouldn't mind getting Zaheer's opinion on whether this looks OK...
Comment on attachment 146379 [details] [review] mpegtsdemux: Don't send new-segment with start time == -1 patch looks good, go ahead and commit
Pushed: commit 91499fd9a78c2175f6be64d655ab8bedfc86fc9e Author: Jan Schmidt <thaytan@noraisin.net> Date: Tue Oct 27 22:08:42 2009 +0000 mpegtsdemux: Don't send new-segment with start time == -1 When sending new-segment to a stream, ensure that there is either a valid PCR, or else wait until there's a PTS on the stream (dropping packets if needed) in order to avoid generating an invlaid new-segments event. https://bugzilla.gnome.org/show_bug.cgi?id=595161