feat: ffmpeg plugin enabled in wheels

[bhack]

Following a similar thread at meta-pytorch/torchcodec#1149

Can we find a way to enable [ffmpeg] plugin in the packaged/distributed wheels?

[lgritz]

Yes, we'd like that, and we have basically the same issues as described in that other thread:

• If we statically link ffmpeg's libraries into our python module (as we do with all the other dependencies), then the combination becomes some flavor of GPL, which severely inhibits what downstream recipients can do with it.
• If we dynamically link (which at least is kosher for LGPL), we have to solve the problems of (a) how to download and build (or install) ffmpeg during pip install, and (b) how to ensure that this does not conflict with any existing or future ffmpeg installations on the same system.
• We'd still need an ok from somebody who knows more about the licensing issues to give us guidance and also provide a clear message for what people downstream of our package are allowed to do.

Another strategy I was thinking about (which I have not had any legal authorities weigh in on) is whether we can switch from a compiled-in ffmpeg support to one that is not linked at all but is purely a dynamic plugin setup. So you'd have two packages: openimageio itself, which would not include the (presumed dynamically loaded) ffmepg support and thus would be entirely our usual Apache-2.0 license, and a separate openimageio-ffmpeg package providing the ffmpeg support as a plugin (and can be dual-licensed as LGPL if need be, which is fine because somebody downstream would need to install it separately). So at no point would the tightly separated ffmpeg parts be part of the same download/install or the same library as the rest of OpenImageIO, but they would be able to find each other at runtime if the downstream users proactively makes sure both are installed and therefore assumes responsibility for it. Would that keep everybody safe?

[bhack]

If you see Torchcodec still enable ffmpeg in the wheel but it is going to require users to have ffmpeg installed when using ffmpeg features. I think also imageio has a similar approach.
See also https://github.com/meta-pytorch/torchcodec/blob/main/packaging/build_ffmpeg.sh

[lgritz]

Yes, exactly. We need a way to arrange it so that we aren't shipping any ffmpeg code in the wheel itself, and that the ffmpeg features require ffmpeg to be installed at runtime to be fully functional, otherwise they will just be disabled without harming other OIIO operations.

[lgritz]

I think this might be achievable easily.

We already have a build-time option to make all the readers/writers be either separate dynamically loaded plugins, or compiled into the main library (the default).

• Make it so that individual plugins can be specified as always being plugins, overriding the global option.
• Do so for ffmpeg and libheif.
• Ship those plugins with the wheel, BUT NOT the libheif or ffmpeg libraries themselves.
• Therefore, the plugins should simply fail to load at runtime if the dependencies are not installed.
• But, I hope, that will just disable the ability to read those files, but leave all other OIIO functionality.

[bhack]

I've tested a lot this in torchcodec and the machinery is working relatively well. So I think we could achieve something similar.