On Tue, 20 Feb 2018 08:47:51 -0300 James Almer <jamr...@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. 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. The security argument is absurd, because you'd just disable them at compile time, and if you really want to restrict components at compile time, there's this whitelist stuff for codecs and a few other things. I feel like I've written this post 3 trillion times, and Michael never read any of them. > > > >> Whatever is done, in any case, should be decided fast. The current new > >> API is in the tree and should be removed without delay if we decide to > >> not use it in the end, even if a proper replacement is not written in > >> the short term. > > > > What needs to be done is testing and applying these patches. > > What makes me uneasy is that if this API remains is place, introducing a > new better one would be annoying for downstream users if it's added too > close to the end of the old API's deprecation period, be it before or > after. Having to migrate a second time in a short time frame is undesirable. > > In any case, just my two cents. Don't take this as a blocker for this > set, but as a request to consider better alternatives in the short or > long term. Like what? What color is it going to be? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel