GNOME Bugzilla – Bug 642526
gdppay: live pipelines stall if seek/newsegment position is nonzero
Last modified: 2018-05-12 10:57:36 UTC
Created attachment 181096 [details] script to reproduce Live pipelines containing gdppay will not begin playing immediately if the initial newsegment event has a nonzero position. For example, consider the following pipeline: audiotestsrc ! gdppay ! progressreport update-freq=1 ! fakesink sync=true Progress reports should start appearing almost immediately after setting the pipeline to the PLAYING state: progressreport0 (00:00:01): 0 seconds progressreport0 (00:00:02): 1 seconds progressreport0 (00:00:03): 2 seconds ... Now, tell the source element, audiotestsrc, to seek to a position like 900000000 * GST_SECOND. If you do this, then you will have to wait 900000000 seconds until the first progress report appears: progressreport0 (00:00:01): 900000000 seconds progressreport0 (00:00:02): 900000001 seconds progressreport0 (00:00:03): 900000003 seconds ... (See the attached gst-python script, doesntwork.py, to reproduce.) On the other hand, if you take out the gdppay element, like this: audiotestsrc ! progressreport update-freq=1 ! fakesink sync=true then progress reports will start appearing immediately either way. The issue seems to be that regardless of what newsegment event gdppay receives on its sink pad, it will always push the same newsegment event in BYTES format on its src pad. This makes it so that the ultimate sink element in the pipeline never gets the segment information it needs. A possible fix, implemented in the attached patch, is for gdppay to save any newsegment event that it receives on its sink pad, and later forward it on its src pad. Since gdppay preserves buffer timestamps, if the original stream had a TIME-formatted newsegment, the original newsegment event should make sense even in the context of the gdp buffers that are flowing downstream. A possible refinement of this patch would be to only forward the original newsegment event if it is in the TIME format.
Created attachment 181097 [details] [review] proposed patch for gdppay in gst-plugins-base
Comment on attachment 181097 [details] [review] proposed patch for gdppay in gst-plugins-base I don't think this is correct, gdppay will always output a single, open-ended BYTES segment. Inside the gdp stream it should however place the newsegment event information and the depayloader should use it to prevent problems like the one you noticed Does it?
gdp now lives in -bad, moving bug there.
This is using seek in ready (which isn't supported) and against 0.10. If you can reproduce this bug with current GStreamer, please re-open.