[FFmpeg-devel] [RFC] 2 Alternative approaches for AVFrame QP Tables

[Anton Khirnov]

Quoting Michael Niedermayer (2020-02-29 13:21:52)
> 
> [PATCH 1/4] Remove all uses of AVFrame QP tables and related fields
> [PATCH 2/4] avutil/frame: Rename QP related fields so unintentional
> 
> These 2 are common in both options, they break API but not ABI so
> should not be applied before the next release
> 
> 
> [PATCH 3/4] avutil: frame Update the existing QP API
> 
> This is a rough sketch of how the existing API can cope with a much
> wider range of codecs.
> I did not check if this is enough to handle every codec that has QP
> values but a variant if this should be able to work with all.

IIUC your proposed function fills in all the values based purely on
type, assuming constant block size for given type. How would that work
for modern codecs with adaptive block sizes?

I suppose it could be extended to read this information from some extra
array appended to the data, but seems to me we'd quickly converge to
just another binary representation of what the other patch does more
explicitly. So I'd say we should go with Juan's patch.
> 
> 
> [PATCH 4/4] libavutil: AVEncodeInfo data structures
> 
> This is the alternative to 3/4, which is Juan De Leóns patch
> which was previously posted and discussed.
> IIUC there where no objections to this previously but it
> was not applied by anyone.
> So Maybe we can just use this. The disadvantage here that i
> can see is primarely that every codec has to convert its
> internal format to the one specified in the API.

That does not seem such a big problem to me, since there are in effect
only two codecs to convert - mjpeg and and mpegvideo.

> In effect this would need a switch to only export
> such data when needed. Because otherwise it would waste time.

I believe that switch would be a good idea in any case, otherwise we do
unnecessary copying of data that most users won't need.

There are some things I would prefer changed in the 4/4 patch API-wise,
but since the original submitter is no longer around I volunteer to do
those changes myself, if you have no objections.

-- 
Anton Khirnov