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

Anssi Hannula anssi.hannula
Sat Jan 1 21:37:44 CET 2011


On 01.01.2011 22:18, Martin Storsj? wrote:
> On Sat, 1 Jan 2011, Anssi Hannula wrote:
> 
>> 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:
>>>>
>>>>> 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().
> 
> No, it can be solved relatively cleanly, check how we did it for 
> av_reigster_protocol2.

What I meant is that simply keeping "next" field at a constant location
doesn't solve the issue alone.

Adding a new function that takes a size parameter would obviously allow
self-registered muxers to continue to work.

> In short, for av_register_protocol2, we solved this by adding a size 
> parameter, where the caller specifies how large the struct passed in is. 
> In av_register_protocol2, we check if this is smaller than what we expect. 
> If it is, we malloc a new internal copy, where we copy as many bytes as 
> the caller specified and zero the rest, which then is registered. (This 
> internal copy is leaked memory, but that is less bad than failing brutally 
> and mysteriously, adding to our reputation of breaking ABI. And it is 
> fixed as soon as the caller is recompiled.) Additionally, the fallback 
> av_register_protocol calls av_register_protocol2 with the size of the 
> previous version of the struct, and is removed at the next major bump.

-- 
Anssi Hannula



More information about the ffmpeg-devel mailing list