stream.ffmpegmux: remove avconv #4826
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The libav (avconv) fork of FFmpeg has been abandoned since several years with its last release in February 2018. There is no reason to still support it. Everyone who's switched to libav in 2011 has switched back to FFmpeg years ago. The only popular Linux distros which default to libav are outdated Debian releases (Jessie) and forks of it (Ubuntu 14). Debian's Stretch release switched back to FFmpeg in 2017 (announced in 2015).
However, as #4825 has just shown again, these old FFmpeg versions and abandoned FFmpeg forks don't always work when remuxing streams. Users of Streamlink are supposed to be using up-to-date and maintained dependencies.
Since we're about to release 5.0.0, let's remove the avconv fallback executable name from the list of default FFmpeg executables. If people still want to use their ancient avconv binaries, they can via
--ffmpeg-ffmpeg
, but there's no reason for Streamlink to unnecessarily cause issues and confusion.Another problem is that Streamlink doesn't log the FFmpeg version that's in use, and errors are also silently ignored. I will take a look at including the version output of FFmpeg in the debug log, but I don't think I want this included in the 5.0.0 release, because this requires a bit more code than just using the available high-level subprocess/asyncio interfaces of the stdlib which read the entire stdout into memory at once. When choosing the wrong executable, this can lead to serious issues. I'm saying this with a potential version validation in mind. But that's a bit off-topic.