[FFmpeg-devel] [PATCH 1/2] lavf: add AVOption support for muxers

[Martin Storsjö]

On Sat, 1 Jan 2011, Michael Niedermayer wrote:

> On Sat, Jan 01, 2011 at 06:44:55AM +0200, Anssi Hannula wrote:
> > On 29.12.2010 14:19, Stefano Sabatini wrote:
> > > On date Wednesday 2010-12-29 13:58:00 +0200, Anssi Hannula encoded:
> > >> On 29.12.2010 13:40, Stefano Sabatini wrote:
> > >>> On date Wednesday 2010-12-29 06:54:14 +0200, Anssi Hannula encoded:
> > >>>> ---
> > >>>>  libavformat/avformat.h |    2 ++
> > >>>>  libavformat/utils.c    |    4 ++++
> > >>>>  2 files changed, 6 insertions(+), 0 deletions(-)
> > >>>>
> > >>>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> > >>>> index c6f2827..9eab2da 100644
> > >>>> --- a/libavformat/avformat.h
> > >>>> +++ b/libavformat/avformat.h
> > >>>> @@ -368,6 +368,8 @@ typedef struct AVOutputFormat {
> > >>>>      const AVMetadataConv *metadata_conv;
> > >>>>  #endif
> > >>>>  
> > >>>> +    const AVClass *priv_class; ///< AVClass for the private context
> > >>>> +
> > >>>>      /* private fields */
> > >>>>      struct AVOutputFormat *next;
> > >>>>  } AVOutputFormat;
> > >>>
> > >>> Put this after the "next" field or it will break ABI (note for the
> > >>> committer: bump minor).
> > >>
> > >> Well, I thought the /* private fields */ meant that the lavf internal
> > >> variables are last so that they can be added/removed/modified at will
> > >> without breaking ABI, which only works if they indeed are the last ones.
> > >>
> > >> But if that is not the intention, priv_class can be put last (it is public).
> > > 
> > > If the "next" field is not used outside lavf then it should be safe to
> > > keep it at the end of the struct.
> > 
> > Well, it shouldn't be, but we can't be sure.
> > 
> > I guess the question is, do we care if applications wrongly using it
> > break? (I don't know the answer to this)
> 
> applications using private fields are writtenm in the knowledge that they will
> stop working the next commit to ffmpeg

What about applications registering muxers/demuxers of their own? In that 
case, the AVOutputFormat is allocated statically in their binary. Do we 
need something like av_register_protocol2, where the caller provides the 
size of the struct as a parameter, or do we simply not care about those 
cases?

// Martin