Which versions of ffmpeg does ffmprovisr support?

[brainwane]

Which versions of ffmpeg does ffmprovisr support? For example, I'm using ffmpeg 4.3.4 on Debian buster, and I see ffmpeg 5.0.1 was released on 2022-04-04.

Is there a range of versions that ffmprovisr recipes should work with? Maybe 4.3.x and above?

If maintainers can consense on a range, I suggest that support window be added to the last paragraph in the "Making FFmpeg Easier" section at the top of the page, or the footer, and I suggest it be added to the README in the Guidelines for contributing.

[kieranjol]

I think that this could work, but I'd be at a loss about how to maintain it. Would someone be tasked with compiling a bunch of tests that can run against a new major version of FFmpeg? The concat example you mentioned is interesting, as it looks like this was the commit that caused it FFmpeg/FFmpeg@46fb395 and I wouldn't know which version this commit made it into. I think that it has been quite rare for FFmpeg to make changes that have resulted in recipes being broken, so I'm not sure if this is a priority? It could be interesting for someone to write a bunch of tests though that run on a regular basis, or is perhaps launched when a new version launches?

[privatezero]

I don't think this would be practically maintainable (and don't think it is necessary as @kieranjol notes the changes that arise usually are rather minor). Within the current structure specific formulas can have notes if they are relying on filters etc. that have been added in a certain version of FFmpeg, which when combined with tweaking formulas as needed seems the most durable in the long-term.

[brainwane]

I wasn't really considering this as a promise to support new versions as soon as they come out. Sorry for accidentally implying that! I should reframe:

Do you have a problem where users frequently ask for help, and then it turns out they're using super old versions of ffmpeg, and that's why the recipe doesn't work for them? Or, do you think that's likely to happen in the future, because of particular breaking changes that happened with particular releases, or redistributors/operating systems/appliances that are likely to get stuck on aging versions?

If so, I figure it's worth saying, somewhere, that all these recipes assume the user is at least at version [n]. And then, given that this isn't a project with a ton of financial and people resources behind it, it's likely not feasible to set up and maintain a test suite, but if a recipe breaks because of a change in ffmpeg, you will eventually (likely) get a bug report.

If those aren't problems you're facing, please feel free to close this issue as WONTFIX!

[kieranjol]

I think that the actual FFmpeg User and Developer official mailing lists get around this by just saying 'we only support GIT HEAD/MASTER' here.
Anyhow I don't think that we have ever received many issues that were due to older versions, your example was one of the rare ones. Picking a version could be hard, we might need to back up that claim and actually test to make sure that everything works. Even if we picked the very latest version, we should still test to see if that claim is true?
I actually think this could be a fun project for someone learning FFMPEG, to see if all the recipes still work! However I'd be in favour of closing this issue, but I'll keep the idea in mind.

[ablwr]

Hmm, I agree about the maintainability difficulty -- AFAIK we haven't received issues about older versions. And anecdotally, I've used several of these during my time at Artefactual, which was maintaining the default FFmpeg versions back on Ubuntu/CentOS 16.04. I don't remember what version that is, but it may have been as low as 2.x (likely 3.x)?

I like the idea that individual recipes could note "version x and above" if they seem recent.

Like @kieranjol and @privatezero said, I also haven't run into many breaking changes between versions for FFmpeg, especially for these mainstream flags/features, which is really nice of them.

That being said, there could be space and phrasing either in the README or on the site itself that makes whatever the consensus is here clear -- that we don't really know or test, and recommend using the latest stable build (I don't think you're recommending this, but want to note that I don't think we should recommend latest git head/master like the list!).

[kfrn]

I agree with the consensus here, perhaps add some kind of disclaimer somewhere about using the latest version?

It'd be very cool to have a test suite set up to do regression testing, but I'm definitely not in a position to take that on 😀

I like the idea that individual recipes could note "version x and above" if they seem recent.

+1 to this

I also haven't run into breaking changes before, though I use ffmpeg rarely these days. 🥲

[kieranjol]

That being said, there could be space and phrasing either in the README or on the site itself that makes whatever the consensus is here clear -- that we don't really know or test, and recommend using the latest stable build (I don't think you're recommending this, but want to note that I don't think we should recommend latest git head/master like the list!).

I agree with every point here! Being open about not knowing, recommended the latest stable build/release etc.

[kfrn]

Also, this:

I actually think this could be a fun project for someone learning FFMPEG, to see if all the recipes still work!

I can see that as a real win-win! If anyone knows someone who's keen to learn ...

[kieranjol]

I might know someone actually...

[retokromer]

We at AV Preservation by reto.ch regularly check that all our scripts and commands work fine. We consider the releases 5.0.1, 4.4.2, 4.3.4 and 4.2.6, but not longer systematically the releases 4.1.9, 3.4.10, 3.2.17 and 2.8.19, for the reasons indicated (in German) on our website. It would not be a big deal to include the ffmprovir recipes into the test loop.