[Bug 757548] New: aggregator: Forced to produce data in paused state

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=757548

            Bug ID: 757548
           Summary: aggregator: Forced to produce data in paused state
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: nicolas.dufresne at collabora.co.uk
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 314772
  --> https://bugzilla.gnome.org/attachment.cgi?id=314772&action=edit
A workaround patch (with mix locking fix, sorry)

This issue is a bit complicated, I might be explaining it badly. Here's the
pipeline I'm am using (rtpsrc is a simplification)

  ( rtpsrc ! decoder) ! ( audiointerleave ! alsasink )

Audio interleave have 3 additional pad requested, but currently unlinked. So
the only way for that element to produce data, is to trigger a timeout (because
of the unlinked pads). Now, to schedule a timeout, we need a clock and a base
time, which is normally available when the transtion to PAUSED_TO_PLAYING is
called on the element. Currently, we try and get this information from the pad
activation, and then every-time a buffer comes in. We don't sync with the state
lock (in fact, it's probably had to do so), and we may endup with half the
information we want (a clock with base_time = 0). In this case we schedule the
next timeout, but it's quite wrong and everything fall apart.

As you can see, in my pipeline, the interleaver is next to the sink, and
contained in the same bin. I'm no expert, but that bin won't transition to
playing until data have reached the sync. Effectively, the transiton to PAYING
never happens on the interleaver, unless we are lucky, and base_time was set.

In such live element, the normal way, is to not produce data until we reached
PLAYING state, and return NO_PREROLL in the TO_PAUSED and TO_PLAYING
transition. But to decide if we should return that, we'd need to know if we are
live or not. This is usally done doing a latency query. Unfortunately, it is
too soon in READY_TO_PAUSED transition.

Find attach my current workaround, note that it bring back this idea that
latency > 0 means live. It's a bit unfortunate, since latency = 0 works fine
now in live since we have fixed the queue to never block before 2 buffers where
queued.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.