Details of writing a decide_allocation routine?

[Stirling Westrup]

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?


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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le ven. 4 janv. 2019 14 h 41, Stirling Westrup <[hidden email]> 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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel