GNOME Bugzilla – Bug 664290
[0.11] Add event/query for buffering requirements
Last modified: 2011-12-01 10:29:45 UTC
There should be some way to query downstream and/or upstream about the number of buffers (or the time or number of bytes) it is going to buffer. This is necessary to get the minimum number of buffers required to pre-allocate for things like OpenMAX or V4L2 before playback starts to make sure that enough buffers are allocated and the pipeline never runs out of buffers. It could be implemented similar to the LATENCY event/query. Elements would first query the other side, then add their own buffering requirements on top of that and return that value.
There's min_buffers in the allocation query (params) - is this not what you had in mind?
I don't really know how this is supposed to work. Are elements supposed to set the min/max buffer fields on the way downstream to reflect their buffering requirements (and the other fields, like the meta, etc are set on the way downstream too) and then on the most downstream element (that sets the buffer pool etc) these values are taken into account and then everything is returned back upstream? And if the buffering requirements somewhere change a reconfigure event must be sent and a new allocation query has to be performed? Is this how the allocation query should be used?
(In reply to comment #2) > I don't really know how this is supposed to work. Are elements supposed to set > the min/max buffer fields on the way downstream to reflect their buffering > requirements (and the other fields, like the meta, etc are set on the way > downstream too) and then on the most downstream element (that sets the buffer > pool etc) these values are taken into account and then everything is returned > back upstream? And if the buffering requirements somewhere change a reconfigure > event must be sent and a new allocation query has to be performed? > > Is this how the allocation query should be used? Not really. The query goes all the way downstream, then upstream elements adjust the query result. At one point some upstream element can choose to use the bufferpool in the query (after configuring and activating it) or use its own allocation method to allocate buffers based on the properties in the queries. This only works with fixed size buffers (pools can only have fixed size buffers). If the parameters change, a reconfigure event needs to be sent. This should be good to negotiate things for v4l2src and sinks. There is no way to add min/max values for bytes in there (use case? you would split those up in buffers of equal size usually) You can also use a new allocator if you have special memory of some sort, the allocator can allocate in different sized chunks. This could be interesting to deal with input memory for a decoder, for example. Again, there is no way currently to negotiate min/max size of this area but it could be done. There is currently also no query for the amount of buffering taking place (amount of buffered bytes and buffers). I don't know why you would need that?
I don't really know use cases for byte/time buffering so let's ignore that for now :) So how would the allocation query be used in this scenario: OpenMAX decoder wants to know the number of output buffers it has to allocate at minimum. And it can't use a buffer pool but has to allocate the buffers itself.
> So how would the allocation query be used in this scenario: > OpenMAX decoder wants to know the number of output buffers it has to allocate > at minimum. And it can't use a buffer pool but has to allocate the buffers > itself. The decoder does an allocation query downstream, it can use the pool from downstream or it can create a pool itself with the min/max buffers in the query result.
But this does not provide the decoder with the buffering requirements of all elements between the decoder and the sink. The min/max buffers in the query result are only set by the sink (or whatever answers the query and provides a buffer pool) and is not the maximum of all elements.
So, what shall we do about this? I'd propose a "buffering" (better name? buffering exists already) query and event that works the same way as the latency query/event and (for now) only works with the number of buffers.
(In reply to comment #7) > So, what shall we do about this? About what? > > I'd propose a "buffering" (better name? buffering exists already) query and > event that works the same way as the latency query/event and (for now) only > works with the number of buffers. Why would you add another query for something that is already handled by the ALLOCATION query?
See comment 6, the allocation query does not handle or solve this because the min/max buffers are only set by the sink
(In reply to comment #9) > See comment 6, the allocation query does not handle or solve this because the > min/max buffers are only set by the sink Any element in between can modify the values and add its own min/max requirements.
Are the min/max values something that has to be configured on the bufferpool before it is used by an element by taking the values from the allocation query? Then this would work, yes
(In reply to comment #11) > Are the min/max values something that has to be configured on the bufferpool > before it is used by an element by taking the values from the allocation query? > Then this would work, yes Yes, you get min/max values in the allocation query then you can change or use those to configure the min/max in the provided pool (or your own pool or something else) It was designed to work with this use case so it should work.
Thanks for clarifying :)