[FFmpeg-devel] [PATCH] Set native order for wav channel layouts up until 8 channels.
Marton Balint
cus at passwd.hu
Sat Feb 24 00:57:14 EET 2024
On Fri, 23 Feb 2024, Romain Beauxis wrote:
> Le ven. 23 févr. 2024 à 15:11, Marton Balint <cus at passwd.hu> a écrit :
>>
>>
>>
>> On Fri, 23 Feb 2024, Romain Beauxis wrote:
>>
>> > The new default channel layout for the various RIFF/WAV decoders is not
>> > backward compatible.
>> >
>> > Historically, most decoders will expect the channel layouts to follow
>> > the native layout up-to a reasonable number of channels.
>> >
>> > Additionally, non-native layouts are causing troubles with filters
>> > chaining.
>> >
>> > This PR changes the default channel layout reported by RIFF/WAV decoders
>> > to default to the native layout when the number of channels is up-to 8.
>> >
>> > The logic for these changes is the same as the logic for the vorbis/opus
>> > decoders.
>>
>> For Vorbis the channel layout is in the actual Vorbis specification. So
>> you should follow the specification, simple guessing in the demuxer likely
>> won't be acceptable.
>
> I would argue that even though there is no official specification on
> channel layout for wav/riff, the de-facto assumption that _most_ users
> of the library would expect is the native layout.
I think this a good starting point:
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html
>
> Typically, 1 and 2 channels would be assumed to be mono and stereo by
> most users.
>
> It's great that the API does provide flexibility but the default
> should be set to satisfy most users and, in that regard, it seems that
> assuming a native layout is what the vast majority of library's users
> will expect.
Actually ffmpeg.c used to have some channel layout guessing code for
exactly this purpose. Maybe you should check why that does not kick in.
>
> This choice also implies at least two ABI breakage for applications
> using the deprecated API but running on a the new ABI:
>
> 1: With the updated API, the library is not able to provide a backward
> compatible `channel_layout` for AVFrame when the new channel order is
> AV_CHANNEL_ORDER_UNSPEC which breaks ABI compatibility as the field is
> reported as `0`.
I believe this was valid even before the new channel layout API for
unknown channel layouts, so I don't quite see the API break.
>
> 2. AV_CHANNEL_ORDER_UNSPEC channel order also breaks filters chaining.
> The issue appears to be that the unspec channel order implicitly sets
> the the filter to accept all channel order, which breaks compatibility
> here:
>
> if (link->incfg.channel_layouts->all_layouts) {
> av_log(link->src, AV_LOG_ERROR, "Cannot select channel layout for"
> " the link between filters %s and %s.\n", link->src->name,
> link->dst->name);
> if (!link->incfg.channel_layouts->all_counts)
> av_log(link->src, AV_LOG_ERROR, "Unknown channel layouts not "
> "supported, try specifying a channel layout using "
> "'aformat=channel_layouts=something'.\n");
> return AVERROR(EINVAL);
> }
A specific ffmpeg command line which shows this error would be useful.
Maybe this can be fixed, if this is a regression.
Regards,
Marton
More information about the ffmpeg-devel
mailing list