GNOME Bugzilla – Bug 654657
tsdemux: newsegment for push-mode is wrong
Last modified: 2011-07-16 12:01:06 UTC
While ranking up tsdemux to PRIMARY + 1 and running the following pileline, I got some assert, and an initial newsegment not sent due to bad parameters. gst-launch playbin2 uri=http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 (gst-launch-0.10:28748): GStreamer-CRITICAL **: gst_event_new_new_segment_full: assertion `start != -1' failed (gst-launch-0.10:28748): GStreamer-CRITICAL **: gst_mini_object_ref: assertion `mini_object != NULL' failed (gst-launch-0.10:28748): GStreamer-CRITICAL **: gst_pad_push_event: assertion `event != NULL' failed (gst-launch-0.10:28748): GStreamer-CRITICAL **: gst_mini_object_ref: assertion `mini_object != NULL' failed (gst-launch-0.10:28748): GStreamer-CRITICAL **: gst_pad_push_event: assertion `event != NULL' failed
*** Bug 654658 has been marked as a duplicate of this bug. ***
Created attachment 192058 [details] [review] Don't create bad segment if PCR is missing Looks like we didn't handle stream without PCR.
Review of attachment 192058 [details] [review]: It's actually not right yet, in my testing with playbin2 uri=http://devimages.apple.com/iphone/samples/bipbop/bipbopall.m3u8 and tsdemux ranked higher, I get tinypts at 10 seconds, and with no surprise, the pipeline waits for 10 seconds before playback start. Thus I think there must be something else to consider here.
The problem is that the newsegment creation is just wrong for push-mode (and needs serious cleanup for pull-mode). Here is what the segment should be like for push-mode in bytes: start : first observed PTS value (in your example that would be tinypts of 10s) stop : last PTS you'll output (if you don't know, put GST_CLOCK_TIME_NONE) position : What the 'start' buffer value corresponds to in streaming time (0 in this case, it's the beginning). for push-mode in time it would work slightly differently, in the sense that we should be pushing out the newsegment we received from upstream and convert the outgoing buffer timestamps based on an interpolation of capture time vs PTS (i.e. estimating the remote transmission clock).
(In reply to comment #4) > Here is what the segment should be like for push-mode in bytes: > start : first observed PTS value (in your example that would be tinypts of > 10s) All this is pretty much the conclusion I had yesterday before I stopped for the weekend. But I wanted to mention that this tinypts stuff looks like a hack, I think this information is already saved somewhere, and if not, we should simply save it as we go instead of doing obscure iteration on all streams.
commit 9f1511e998f5f7c35224dfef05cce0c8083658e4 Author: Edward Hervey <bilboed@bilboed.com> Date: Sat Jul 16 13:44:00 2011 +0200 tsdemux: Fix newsegment creation for push mode And all relevent comments to what it should be doing, refactor everything a bit. Still not perfect ... but better. Fixes #654657