Why We're Forking PyAV

WyattBlue   March 2, 2025

A few weeks, jlaine and I had a disagreement on how to handle source builds on PyPI. I argued that it misleads pip because it claims no platform restricts. jlaine dissented and, eventually, I relented and restored “sdist” builds. This did not mean, however, that I was convinced that my arguments are wrong. Instead, I saw a growing divide between my needs and the community.

Differences

My focus is making PyAV as good as possible for commercial video editing. That meant packaging PyAV differently than the community builds.

There are currently two PyAVs on PyPI:

• av: The official and community build. There is no active PyPI admin, that means no release can ever be deleted, even if it’s just a release candidate.
• pyav: Same Cython code, different build. I am the PyPI admin.

The former is built with the GPLv3 compatible features and third party libraries, notably x264 and x265. My package is built with LPGLv3 compatible features and libraries.

I also wish for changes that make the material conditions of using parallel code better and to more aggressively drop support for End-of-Life operating systems and python versions.

Our New Fork

My fork will continue in the tradition of the pyav builds. The difference is that the Cython code

Because of the similar names, av and pyav, it’s easy to conflate the two. That’s why I don’t want to publish in pyav even though I have admin rights on PyPI. Instead, I created a new name: BasswoodAV

You can install with:

pip install basswood-av

And you can find the source code here. We also do our own ffmpeg builds.

A Friendly Fork

I still plan to maintain PyAV. I just won’t be as active in the project.

To help maintain distance, this fork will use a different name: basswood-av, rather than continuing to use pyav. The latter will either be deleted, returned, or just remain inactive.

You can pretty much consider BasswoodAV as a drop-in replacement for PyAV. For example, you can still do:

import av

You can see the changelog for any differences between PyAV and BasswoodAV.

Q.A.

What About The Docs?

The docs for the fork live on https://av.basswood-io.com. The PyAV docs still live in https://pyav.basswood-io.com, although I plan to eventually move them to a different url.

What Will This Mean for Auto-Editor Users?

If you’re using the Auto-Editor app, you don’t really have to worry about this at all. If you’re using auto-editor cli>=27.0, you may want to run:

pip uninstall av pyav
pip install basswood-av

although this shouldn’t be necessary if you’re managing auto-editor with pipx or similar.

What Will This Mean for PyAV Users?

If you’re already using pyav, I highly recommend switching to basswood-av once version 15 is ready.

Otherwise I recommend staying with PyAV (av) if you don’t need the bleeding edge features. PyAV is not deprecated, and I’m sure some of the features from BasswoodAV will come back to PyAV eventually.

What Will This Mean for Package Managers?

av/python-av and basswood-av are not the same project. Each would need to be packaged separately.

Could The Projects Ever Converge?

One feature that would make this a lot easier would be the ability to dynamically load external libraries such as libx264 on the users system without having to package it statically. This would allow the use of GPLv3 compatible and LGPLv3 compatible libraries without legal issues.

Unfortunately, this doesn’t solve the policy issues that I have with PyAV. There isn’t a technical solution that could do that.

Can I See The Logo Again?

Sure.