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

Anssi Hannula anssi.hannula
Sat Jan 1 05:44:55 CET 2011


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)

-- 
Anssi Hannula



More information about the ffmpeg-devel mailing list