Details of writing a decide_allocation routine?

[Nicolas Dufresne]

Le ven. 4 janv. 2019 14 h 41, Stirling Westrup <swestrup at gmail.com> a
écrit :

> I need to write a generic decide_allocation routine for a new type of
> device-hardware memory we're implementing in a product, and I'm unsure
> of the priorities to give to the various parts of a GstQuery.
>
> To make things simpler, assume that I have already filtered the
> GstQuery response to remove all inappropriate pools and parameter
> sets, and that there are still at least one proposed pool and one
> proposed allocation params left.
>
> Taking a look at the various implementations of decide_allocation out
> there, it looks like a typical implementation does this:
>
> 1) If there are one or more proposed buffer pools, take the first one
> as our accepted pool type. If there are no proposed buffer pools,
> create one of a default type.
> 2) If there are one or more proposed allocation parameters, take the
> first one as our proposed parameters. If there are no proposed
> allocation parameters, then create a default one.
> 3) Apply the parameters from step (2) to the pool determined in step
> (1), even if that means reprogramming an existing pool with default
> parameters.
>
> Is this correct? Should step 3 perhaps only apply the parameters if
> step 1 created a default buffer pool? I've also seen code that applies
> proposed allocation parameters to a proposed buffer pool, is that
> correct?
>

At the moment, most specialized pool simply ignore the allocation params,
so it does not really matters. This is mostly past as a hint.
Unfortunately, a lot of validation is missing all over the place, so it's
not impossible we will hit some issues with this at some point in time.


>
> The GstQuery
>
> --
> Stirling Westrup
> Programmer, Entrepreneur.
> https://www.linkedin.com/e/fpf/77228
> http://www.linkedin.com/in/swestrup
> http://technaut.livejournal.com
> http://sourceforge.net/users/stirlingwestrup
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190106/368270d4/attachment.html>