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

Michael Niedermayer michaelni
Sat Jan 1 17:00:13 CET 2011


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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110101/d706c3f7/attachment.pgp>



More information about the ffmpeg-devel mailing list