Hi, On Fri, Oct 27, 2017 at 10:14 PM, Michael Niedermayer < mich...@niedermayer.cc> wrote:
> On Fri, Oct 27, 2017 at 10:03:54PM +0200, Paul B Mahol wrote: > > Signed-off-by: Paul B Mahol <one...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel