On 11/2/17, Michael Niedermayer <mich...@niedermayer.cc> wrote:
> Hi
>
> On Sat, Oct 28, 2017 at 07:43:05AM -0400, Ronald S. Bultje wrote:
>> 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".)
>
> If you say the interface is "ABI/API unstable" then we cannot use it
> from another lib like libavfilter. So this would not work.
I disagree.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
