[Bug 642526] New: gdppay: live pipelines stall if seek/newsegment position is nonzero

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=642526
  GStreamer | gst-plugins-base | git

           Summary: gdppay: live pipelines stall if seek/newsegment
                    position is nonzero
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: lsinger at caltech.edu
         QAContact: gstreamer-bugs at lists.freedesktop.org
      GNOME target: ---
     GNOME version: ---


Created an attachment (id=181096)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=181096)
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.

-- 
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.