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.