PyAV Release Schedule

[WyattBlue]

trafficstars

Here are my thoughts on the current release schedule:

---

v13.0.0 Release date: September 1st or 2nd

• Supports FFmpeg 6 and FFmpeg 7
• Build wheels with Python 3.13
• Drop support for Python 3.8

vx.x.x Release date: 2028

• Drop support for x86 MacOS targets

---

v12.0.0 Released: March 21st, 2024

• Supports FFmpeg 5 and FFmpeg 6
• Builds binary wheels against FFmpeg 6.1.1 and updates internal libraries
• Adds type stubs for type hinting/completion

v12.1.0 Released: May 30, 2024

• Supports FFmpeg 5 and 6

[daveisfera]

Any chance support for ffmpeg 7 could make it out before Oct?

[WyattBlue]

@daveisfera

Any chance support for ffmpeg 7 could make it out before Oct?

FFmpeg 7 removes many deprecated APIs that PyAV still depends on. PyAV would have to changes its public API to match the new ffmpeg APIs, particularly for audio. It would take a lot of work to move the new APIs, then yet more work for figure out an upgrade path for PyAV users. Due to all the time required, I'm anticipating our release to match that for Python 3.13.

Our release dates are still tentative, it could be released in September if the work is done and their is a Python 3.13 release candidate available.

[daveisfera]

Totally makes sense! Definitely appreciate all of the work and looking forward to the release!

[hmaarrfk]

The FFMPEG 6 documentation of FFMPEG 6 is useful in learning how to transition to FFMPEG7 I made a personal attempt in https://github.com/hmaarrfk/PyAV/pull/2 As @WyattBlue mentionned, the real question is what to do about the AudioLayout class of PyAv.

[h-vetinari]

Since I don't see it mentioned, numpy 2.0 is going to come out soon as is probably worth taking into account: #1401

[jlaine]

I disagree with dropping Python 3.8 already, especially in a minor release. Python 3.8 only reaches end-of-life in another 5 months.

Dropping Python 3.8 before its end of life makes it impossible to adopt the latest versions of PyAV in projects which support all current Python releases. For instance, I am unable to update aiortc.. which was the reason I got involved in PyAV!

[WyattBlue]

@jlaine Okay, we can build wheels for Python 3.8. It was slowing down CI, but now that smoke tests and publishing is split, it's no longer a big deal.

[WyattBlue]

I don't see any reason to delay 12.1.0's release. If you don't see anything wrong, I could make the release in a day.

Final Checklist:

• [x] Fix tests CI / Build Python 3.8 again
• [x] Use new pyav-ffmpeg binaries
• [ ] Bump version in about.py
• [ ] Write changelog
• [ ] Build and publish new docs
• [ ] Publish to PyPI

[jlaine]

@WyattBlue it looks like the binary FFmpeg builds for macOs are broken, they drag in X11 libraries for the wrong macOs version. This is something which should be fixed today, I explicitly addressed this in my updates to pyav-ffmpeg.

[jlaine]

I also disagree with dropping FFmpeg 5, this is definitely not minor version stuff.

Moreover, FFmpeg 5 is going to be around for a while, for instance it's the version that ships with the Debian stable release.

[WyattBlue]

I also disagree with dropping FFmpeg 5, this is definitely not minor version stuff.

@jlaine Re-adding support for FFmpeg 5 now is difficult because I've promised to remove it for this release since late April.

You could:

• Call the June release 13.0.0, which is technically easy, however, I find this very unsatisfying.
• Make a new branch for 12.1.0 starting from 12.0.0 then cherry pick commits that still work with FFmpeg 5.
• Make a new branch for 12.1.0 starting from main then revert commits incompatible with FFmpeg 5.

Moreover, FFmpeg 5 is going to be around for a while, for instance it's the version that ships with the Debian stable release.

People using old versions of ffmpeg can use old versions of pyav. Debian right now only ships av 11.0.0 or lesser. Also, FFmpeg 7 is going to be around for a while and I would like pyav to support it sooner rather than later.

[jlaine]

We're using semantic versioning, so this means no breaking changes within a major release. So, either:

• You have already made the switch to the new audio channel layout. In this case, FFmpeg 7 is now supported, and FFmpeg 5 is indeed no longer supported. This means the next release is a 13.0.0.
• Or you have not yet made this switch, in which case there is no reason to drop FFmpeg 5, and the next release is 12.x.

AFAICT, commit e884e6cd1dac2646fd002b441ca4fdfb2ef818c5 just stopped testing against FFmpeg 5, so reverting it should be trivial.

EDIT: I just put together PR #1407 which restores tests against FFmpeg 5.x, and the tests do pass, so we are still compatible with FFmpeg 5. Let's merge it, and cut release 12.1.0 as is.