Prepare for audio channel info being stored differently
s09bQ5 opened this issue · comments
The next time the major version of libavutil is increased, the channels, channel_layout, and request_channel_layout fields from AVCodecContext will vanish. They have been deprecated in 2017.
The channels and channel_layout fields have been replaced with the ch_layout field, which is a structure of type AVChannelLayout. Instead of request_channel_layout we need to use the "downmix" codec option to request stereo, which is also of type AVChannelLayout. Only four audio codecs (AC3, DCA, AAC using libfdk, and MLP/TrueHD) have that codec option and these are the same codecs that currently respect request_channel_layout for downmixing.
They have been deprecated in 2017.
The replacement fields, have they also been added in/before 2017? Because that's six years ago now: do we really need to continue supporting even older versions?
I don't really touch this kind of stuff but I sometimes search for IF LIBAV and I'm just not sure if it's worth supporting 10+ years of versions. And most of the hits have to do with very old versions (I think?).
The commit to deprecate the API was authored in 2017, but it was committed in 2022 together with commits that changed all affected decoders to the new API. We would have to drop support for all versions before FFmpeg 5.1.
Ah yeah that does add some nuance to the situation. It read as if 2017-now supported both ways of getting the channel info, but if that's only really 2022-now, that's a different story. I was thinking of maybe supporting only the current + previous major, but isn't something (either Windows, appimage or flatpak) still using 4.x anyway?
I'd be fine having more IF for this then. I was browsing the code yesterday (and looking at FFmpeg supported versions) and it seems that most of the IF statements have to do with 0.x and 1.x anyway. Separate from this audio channel issue, we can probably start dropping those incrementally.