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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
