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

[Anssi Hannula]

On 01.01.2011 21:01, Michael Niedermayer wrote:
> On Sat, Jan 01, 2011 at 06:15:08PM +0200, Martin Storsj? wrote:
>> 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 
> 
> They should submit them to us and not do that :)
> That said iam not against keeping the next parameter at a constant location
> i just dont care too much about it

Wouldn't applications registering their own muxers break anyway?
If added after the "next" field, the new "priv_class" field would be
outside the application-provided AVOutputFormat when checked by
av_set_parameters().

-- 
Anssi Hannula