GNOME Bugzilla – Bug 781721
inter: Add overflow-mode property and alternative "block" mode
Last modified: 2018-11-03 14:07:47 UTC
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?).
Created attachment 350399 [details] [review] Patch for new overflow-mode in inter elements
Created attachment 351065 [details] [review] Patch for new overflow-mode in inter elements , v2 Surface mutex was held during preroll in the sinks. This updated version of the patch unlocks the mutex prior to entering preroll & locks it back after unless the preroll was ended unexpectedly.
Review of attachment 351065 [details] [review]: ::: gst/inter/gstinter.h @@ +27,3 @@ + +typedef enum { + GST_INTER_OVERFLOW_MODE_FLUSH, Flush seems like a weird name. It's "non-blocking", it does not flush :) ::: gst/inter/gstinteraudiosink.c @@ +357,3 @@ + if (g_atomic_int_get (&interaudiosink->unlocked)) { + g_mutex_unlock (&interaudiosink->surface->mutex); + if ((ret = gst_base_sink_wait_preroll (sink)) != GST_FLOW_OK) What is this case and why do we wait for preroll here? Needs a comment. Usually if unlock(), you want to get out of render ASAP and return FLUSHING @@ +363,3 @@ + + g_cond_wait (&interaudiosink->surface->cond, + &interaudiosink->surface->mutex); You need to detect the unlock/flushing case here, in which case you want to go out immediately.
> Flush seems like a weird name. It's "non-blocking", it does not flush :) I called it flush because of the gst_adapter_flush() call in interaudiosink, but perhaps this is too specific. What about "overwrite-oldest"? > What is this case and why do we wait for preroll here? Needs a comment. This follows the GstBaseSink unlock() documentation, which states: "Subclasses should unblock any blocked function ASAP and call gst_base_sink_wait_preroll()" > You need to detect the unlock/flushing case here, in which case you want to go out immediately. This actually already happens. In the unlock/flushing case, the unlock() vfunc is called, which sets the unlocked flag and signals the condition variable.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/549.