[FFmpeg-devel] [PATCH] avutil/frame: Remove requirements to use accessors for AVFrame

[Michael Niedermayer]

On Mon, Jan 09, 2017 at 10:27:09AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Jan 9, 2017 at 8:48 AM, wm4 <nfxjfg at googlemail.com> wrote:
> 
> > On Mon, 9 Jan 2017 08:17:08 -0500
> > "Ronald S. Bultje" <rsbultje at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Jan 9, 2017 at 7:15 AM, wm4 <nfxjfg at googlemail.com> wrote:
> > >
> > > >     /**
> > > >      * Not to be accessed directly from outside libavutil
> > > >      */
> > > >     AVBufferRef *qp_table_buf;
> > > >
> > > > The comment should be adjusted and allow direct access. Also,
> > > > it should be moved out of the FF_API_FRAME_QP ifdef (why was
> > > > it under it anyway).
> > >
> > >
> > > I disagree. FF_API_FRAME_QP is not something that exists or is useful
> > > outside a handful of codecs (basically mpeg-1/2/4). If we want this to be
> > > public API, it should exist in a way that makes it useful to the majority
> > > of codecs that use quantization. I'm speaking codecs not developed by
> > > people that implemented qp_table_buf, for example vp3/5/6/8/9 etc.
> > >
> > > This also means we need a useful way to normalization the quantizer to a
> > > universal scale. Exporting it as SCALE_MPEG, SCALE_H264 etc. is not
> > useful.
> > > We need a universal Q so -sameq has some kind of meaning when re-encoding
> > > mpeg-4 to vp9. Also, aq visualization in libavfilter would suddenly be
> > > meaningful across codecs. Etc.
> >
> > Ah, I thought the QP API survived, but now I see that the accessors are
> > within FF_API_FRAME_QP as well. So this is not a bug like I thought,
> > but intentional, and all QP retrieval will be removed after the API
> > bump. Just strange that the accessors have no attribute_deprecated.
> 
> 
> I agree that's strange. We should probably add them...

before deprecating the API to access the QP tables a replacement is
needed and uses of teh API should be changed to use the replacement.
Otherwise not only would code using it conflict with a API bump but
also produce warnings about use of deprecated code


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

It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170109/03386fd8/attachment.sig>