GNOME Bugzilla – Bug 792039
h26{4,5}parse: expose chroma format and bit depth in caps
Last modified: 2018-01-24 17:02:08 UTC
Our plan is to use this in the OMX decoder of the ZynqUscale+.
Created attachment 366071 [details] [review] h26{4,5}parse: expose chroma format and bit depth in caps This information could be used for example to pick a decoder supporting a specific chroma and/or bit depth, like 4:2:2 10 bits. It can also be used to inform earlier decoder about the format it is about to decode.
See bug #792040 for the OMX patches.
Review of attachment 366071 [details] [review]: Looks good.
Why is it not enough to pick decoders based on supported profiles here?
Attachment 366071 [details] pushed as a1b271d - h26{4,5}parse: expose chroma format and bit depth in caps
(In reply to Tim-Philipp Müller from comment #4) > Why is it not enough to pick decoders based on supported profiles here? It's a hint to the decoder so it can reduce the size of the first output buffer allocation. If you only look at the profile, you endup always allocating that buffer as if it was going to be the higher depth supported. In general this field can be ignored. I only expect to see this appear in fixed caps to be honest. In the specific figure, we have limited RAM considering we are handling 8 x 4K streams. In addition to that, we are still using CMA, so allocating memory takes a lot of time. By guessing better the output allocation, we end up not having to reallocated and copy later on, saving in startup latency and RAM at the same time.
Obviously, the decoder could parse it, but I forgot to mention that to get rid of the startup latency issues, this decoder will pre-allocate when the caps are set. We make sure these caps are out of band, and then we can ensure the pre-allocation is done before the streams starts flowing (even before the first buffer was encoded/capture).