[FFmpeg-devel] Global state and mutable component lists (was: Plugins architecture)

[Nicolas George <george@nsup.org>]

Lynne (HE12025-08-12):
> > That requires someone to create that "binary plugin interface",
> > that person seems not existing, so i dont think its an "option"
> Its a better option in that its a one-time affair, and also there's no
> endorsement of such plugins by us.

An official binary plugin API requires stabilizing a lot of our internal
APIs, that would be a lot of work and a tremendous drag on development.
I am pretty sure there is a wide consensus against it.

> Also, we had such an infrastructure in the past with users being able to
> give their own AVCodec structures to lavc, without us having guarantees that
> we wouldn't break this.

This is partly true but rather inaccurate. We never had an
“infrastructure” to add components. What we had is mutable components
lists and the symbols to manipulate them public. Applications could
abuse that to insert custom components into the lists. I know it worked
because for a long time I used LD_PRELOAD to inject a demuxer of my own
into mplayer.

But to implement the custom components, applications had to include
uninstalled headers, they have to take them from our source tree. That
made it very clear that they were doing something unsupported.

> It wouldn't take much to revert that and implement support for this, along
> with freezing AVCodec longer-term than major bumps.

I very much oppose freezing AVCodec, especially because it would not be
enough: a lot of internal APIs would need to be frozen as well.

On the other hand, I would like to see mutable components lists back,
but for a completely different reason: to replace our terrible and
unreliable implementation of components whitelists.

And it goes well hand-in-hand with another worthy project of turning our
global state into multiple-allocatable structures.

Here is the idea:

- Applications that use our API need to allocate an instance of an
  AVLibrary object.

  (FreeType does that: “error = FT_Init_FreeType( &library );”
  <https://freetype.org/freetype2/docs/tutorial/step1.html>)

- AVLibrary contains all that is currently global state in our
  libraries: log callback, log level, lock manager, pools, etc., and of
  course component lists.

  (I have a solution that is compatible with having separate libraries.)

- AVLibrary is referenced (refcounted) from contexts, so that it is
  readily available from most of our code base.

- We have to create new versions of the entry points APIs,
  (avcodec_find_decoder_by_name(), etc.) that take an AVLibrary as first
  argument.

- A compatibility layer, quickly deprecated, allocates a global
  AVLibrary once and for all.

With this system, we would implement whitelists by adding only trusted
components to the AVLibrary instance. And people can add custom
components because the lists are mutable.

Regards,

-- 
  Nicolas George
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".