[FFmpeg-devel] [PATCH 1/2] lavf: add AVOption support for muxers
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
> No, it can be solved relatively cleanly, check how we did it for
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.
More information about the ffmpeg-devel