[Bug 664290] [0.11] Add event/query for buffering requirements

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=664290
  GStreamer | gstreamer (core) | 0.11.x

--- Comment #3 from Wim Taymans <wim.taymans at gmail.com> 2011-11-17 19:46:35 UTC ---
(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?

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