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

[Michael Niedermayer]

On Wed, Mar 04, 2020 at 12:55:31PM +0100, Anton Khirnov wrote:
> 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?

Yes
The array would use the smallest block size supported by the codec.
So no block shape information would be exported


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

ok, ill wait a bit in case anyone else has comments though


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

what would be nice in an ideal world, would be to export the
internal format with a stable API thats the same for all codecs 
to the outside without copy.
I guess this is too constraining in reality


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

sure

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20200304/79153013/attachment.sig>