[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