Common/Public Binary Extensions #2350
Replies: 1 comment 1 reply
|
libvmaf is a reasonable candidate, but this is primarily a binary-distribution question rather than a missing PyAV API. PyAV exposes FFmpeg filters generically, so when its linked FFmpeg was built with libvmaf, it should already be available: "libvmaf" in av.filter.filters_availableThe official wheels use the FFmpeg builds from pyav-ffmpeg, whose current configuration does not include libvmaf. Adding it would therefore belong there. I’m open to considering it. The main cost is ongoing maintenance rather than the initial implementation: it needs to build and package consistently across every supported architecture, with binary-size, CI, and dependency updates accounted for. The import order issue should not normally apply. All packages in one Python environment import the same av module; which build is selected is determined by the environment and sys.path, not which dependent package imports it first. Installing a custom PyAV build in that environment should make it the version used by every dependency. A pyav-ffmpeg issue or PR that includes a cross-platform build recipe and reports the resulting archive-size increase would be the best next step. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm curious if thought toward including additional "default" extensions such as libvmaf has been considered. The thought being parity (or at least exposing the option for) with the common public ffmpeg binaries. Custom compiling pyav is possible but introduces some challenges if you are importing modules that ALSO import pyav -- order of import may mean you don't get your variant.
Build complexity and size go up, but that seems likely (especially in the age of AI agent assistance) a small tax for the gain.
Thoughts?
All reactions