[Bug 781721] New: inter: Add overflow-mode property and alternative "block" mode

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 781721
           Summary: inter: Add overflow-mode property and alternative
                    "block" mode
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dv at pseudoterminal.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Right now, the inter elements discard existing data if the channel is full.
This is undesirable if one wants to use inter elements for creating a
"producer" and a "consumer" pipeline. Example:

gst-launch-1.0 audiotestsrc ! interaudiosink sync=false  interaudiosrc !
alsasink

This will output a corrupted sine wave and use 100% CPU, which is because
interaudiosink will output data as fast as the CPU allows - if the channel is
full, it just flushes the oldest samples until there is enough room for new
ones.

This current behavior is retained and remains the default; it is now called the
"flush" mode. The overflow-mode property introduces an alternative behavior,
the "block" mode. In this mode, if the channel is full, inter*sink elements
block until the channel has enough free space. With intervideo and interaudio,
this means that the sink elements block until the corresponding src elements
have read out the last buffer (= the channel has a capacity of exactly one
buffer). With interaudio, this means that the interaudiosink element blocks
until the interaudiosrc element has retrieved period-time nanoseconds of audio
data from the channel.

NOTE: This is a first version that does not include tests yet. Also, the
intersub element changes have not been tested yet because so far I could not
construct a test pipeline because the intersubsink sink caps are incompatible
with existing subtitle parsers (perhaps a good topic for a separate intersub
bugfix?).

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