[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