[FFmpeg-devel] [PATCH 0/3] Finish new iteration APIs

[James Almer]

On 2/20/2018 9:21 AM, wm4 wrote:
> On Tue, 20 Feb 2018 08:47:51 -0300
> James Almer <jamrial at gmail.com> wrote:
> 
>>> It has fully achieved its objectives. There's no more visible global
>>> mutable state, and the actual global mutable state has been reduced to
>>> less than 5 codec entries.  
>>
>> It's true that after the deprecation period they will effectively be the
>> only ones still mutable, but shouldn't the objective be to cover them all?
> 
> That would be nice. But this has been discussed before. No kind of
> different registration API could fix this issue either, unless we start
> mallocing AVCodec structs and require the user to free them, or
> something equally absurd. The proper solution for this specific issue
> would be making a new API that somehow replaces AVCodec.pix_fmts.
> 
>>>
>>> Why are we discussing this _again_?  
>>
>> Because a drawback has been found, namely that link time optimization
>> using static libraries can't remove "non registered" modules anymore,
>> and now depends fully on what's enabled at configure time.
>> Ideally, a better registration based API that follows what i described
>> above should be designed with care.
> 
> Oh yeah, bikeshed attack by Michael. As it was said a few thousand times
> already, public API users could NOT use the registration stuff to
> register only specific components at runtime. So they have to use the
> register_all variants, which pull in _all_ components even with static
> linking.

Oh, i assumed it was possible to use avcodec_register() on a manual
basis in a proper API usage scenario, but i see now that's not the case.

Nevermind then, my argument was focused on preventing losing some link
time optimization for static libraries assuming proper API usage.

> 
> And that can't be made with dynamic linking either. If you statically
> link anyway, you probably control everything, and you can configure this
> stuff at compile time.
> 
> Then I guess there's this very special case where a fuzzer statically
> links to libavcodec, and registers only a few components (technically
> violating the API and by guessing the component symbol name), and
> without calling the register_all functions. This would make the
> resulting executable much smaller, which is apparently important
> because Google (who runs the fuzzers for their oss-fuzz project) is too
> poor (?) to host all the statically linked fuzzers, _or_ the whitelist
> stuff is not enough to trick the fuzzer into not trying to fuzz the
> wrong code. In addition, it's apparently infeasible to just build
> every fuzzer with a separate libavcodec. (Not sure about the details, it
> was something like this.)
> 
> Those requirements are really quite nebulous. I don't know why we even
> should care - surely whoever does this will find a solution that works
> for them. For example they could apply a small patch that makes the
> codec_list[] symbol non-static non-const, which would allow them to
> overwrite it (i.e. deleting unneeded entries). It's a really simple
> solution that took me 5 minutes to come up with.

Something like this is probably the best solution for the fuzzer issue, yes.