[Bug 727611] New: bufferpool: Add _set_flushing() and new (active,flushing) state

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Fri Apr 4 07:36:38 PDT 2014


https://bugzilla.gnome.org/show_bug.cgi?id=727611
  GStreamer | gstreamer (core) | git

           Summary: bufferpool: Add _set_flushing() and new
                    (active,flushing) state
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: nicolas.dufresne at collabora.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


On flush-start we are supposed to unblock everything that could have been
blocked in our element. An existing, but rare, case we have right now is the
when a pool that cannot grow has no more buffer to offer. acquire() will then
block on a internal poll. To unblock this call, we need to call
set_active(FALSE).

While this will correctly unblock any call to acquire, it also has the side
effect of freeing all the pre-allocated buffers and the memory that where
attached to it. This means, that correctly implemented element using buffer
pool would free and re-allocate all of its memory at every seek, even though
the format and required amount of buffers may not have change.

In order to give element a better control, I'm proposing to introduce a new
state, moving the pool from 2 state, active and inactive to 3 states:

inactive -> (!active, flushing)
flushing -> (active, flushing)
active -> (active, !flushing)

The new methods would be called:

gst_buffer_pool_set_flushing (pool, flushing)
gst_buffer_pool_is_flushing (pool)

This would share the same lock used for _set_active(), setting to non-flushing
while not active will not be permitted.

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


More information about the gstreamer-bugs mailing list