[FFmpeg-devel] [PATCH] avfilter: initial macroblock types export and visualization
Ronald S. Bultje
rsbultje at gmail.com
Sat Oct 28 14:43:05 EEST 2017
Hi,
On Fri, Oct 27, 2017 at 10:14 PM, Michael Niedermayer <
michael at niedermayer.cc> wrote:
> On Fri, Oct 27, 2017 at 10:03:54PM +0200, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol <onemda at gmail.com>
> > ---
> > libavcodec/mpegvideo.c | 10 +++++
> > libavfilter/vf_codecview.c | 105 ++++++++++++++++++++++++++++++
> +++++++++++++++
> > libavutil/frame.h | 4 ++
> > 3 files changed, 119 insertions(+)
>
> First, thanks for working on this.
>
>
> [...]
>
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index fef558ea2f..8481dc080b 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -141,6 +141,10 @@ enum AVFrameSideDataType {
> > * metadata key entry "name".
> > */
> > AV_FRAME_DATA_ICC_PROFILE,
> > + /**
> > + * Macroblock types exported by some codecs.
> > + */
> > + AV_FRAME_DATA_MACROBLOCK_TYPES,
> > };
> >
>
> This makes the internal data of the decoder part of the ABI and API of
> libavcodec and libavfilter
> and its undocumented
>
> do people prefer to make the internal data part of the ABI, document
> it and ensure it does not change till the next bump
>
[..]
> or is there some other option iam missing ?
>
I noted this on IRC also. A third option is to not document it and consider
it codec-specific.
(Codec-specific implies "ABI/API unstable" and subject to change - "don't
mix versions".)
> or design a new interface, document it and convert to it?
I think we'd all prefer this, but this requires someone to do the work.
Exciting!
Ronald
More information about the ffmpeg-devel
mailing list