After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694804 - bufferpool: No way to override acquire_buffer to chose a sensible buffer
bufferpool: No way to override acquire_buffer to chose a sensible buffer
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-02-27 16:52 UTC by Sebastian Dröge (slomo)
Modified: 2018-05-04 09:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bufferpool: Allow subclasses to access the queue of buffers (3.39 KB, patch)
2013-03-13 09:02 UTC, Sebastian Dröge (slomo)
rejected Details | Review

Description Sebastian Dröge (slomo) 2013-02-27 16:52:24 UTC
The buffer always has to be returned from the default implementation of acquire_buffer currently because that handles bookkeeping of the internal GstBufferPool state. Also there's no way to get a list of all buffers that are currently there.

The documentation of GstBufferPoolAcquireParams however mentions that custom implementations of acquire_buffer could use the information of the params to chose a specific buffer.
Comment 1 Sebastian Dröge (slomo) 2013-03-13 09:02:00 UTC
Created attachment 238764 [details] [review]
bufferpool: Allow subclasses to access the queue of buffers
Comment 2 Wim Taymans 2013-03-13 09:20:26 UTC
The idea is that you need to overwrite the acquire and release methods and implement your own g_queue and signaling if you want something else.
Comment 3 Wim Taymans 2013-03-13 09:22:58 UTC
I guess my biggest problem is that the pool is now not atomic anymore.
Comment 4 Sebastian Dröge (slomo) 2013-03-13 09:38:12 UTC
Does that really matter?

I don't see how we could allow subclasses to do anything useful in acquire without making the pool not-atomic.
Comment 5 Wim Taymans 2013-03-13 10:12:47 UTC
(In reply to comment #4)
> Does that really matter?

It does to me

> 
> I don't see how we could allow subclasses to do anything useful in acquire
> without making the pool not-atomic.

some options:

- You override the acquire, release and stop methods and take a buffer from
  your own queue/array/whatever you use to implement the pool. We need to make
  do_alloc_buffer() public.

- Implement a method to iterate the queue buffers to filter out a buffer that
  you want.

What exactly would you want to do with the buffers from atomic queue?
Comment 6 Sebastian Dröge (slomo) 2013-03-13 10:28:50 UTC
(In reply to comment #5)

> > I don't see how we could allow subclasses to do anything useful in acquire
> > without making the pool not-atomic.
> 
> some options:
> 
> - You override the acquire, release and stop methods and take a buffer from
>   your own queue/array/whatever you use to implement the pool. We need to make
>   do_alloc_buffer() public.

That would be possible, yes.

> - Implement a method to iterate the queue buffers to filter out a buffer that
>   you want.

I don't think that's possible with the atomic queue without making it non-atomic.

> What exactly would you want to do with the buffers from atomic queue?

In gst-omx I need to acquire a very specific buffer from the pool.
Comment 7 Sebastian Dröge (slomo) 2013-03-14 13:48:43 UTC
Comment on attachment 238764 [details] [review]
bufferpool: Allow subclasses to access the queue of buffers

Let's just add get_buffer() and put_buffer() vfuncs to the pool, for which the default implementation just uses the atomic queue

If someone ever needs that, I don't anymore ;)
Comment 8 Olivier Crête 2018-05-04 09:34:33 UTC
It seems no one else has needed it in 5 years, so let's close this unless someone plan to commit it.