Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Marton Balint <cus@passwd.hu>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH] Set native order for wav channel layouts up until 8 channels.
Date: Fri, 23 Feb 2024 23:57:14 +0100 (CET)
Message-ID: <1a03ad0b-525a-74e6-7ef5-346d455a72e3@passwd.hu> (raw)
In-Reply-To: <CABWZ6OQQyA+0oQejGu_AAdisYAdO7LTwKgN-DFSzmBtRYzmOig@mail.gmail.com>



On Fri, 23 Feb 2024, Romain Beauxis wrote:

> Le ven. 23 févr. 2024 à 15:11, Marton Balint <cus@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2024-02-23 22:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23 20:41 Romain Beauxis
2024-02-23 21:11 ` Marton Balint
2024-02-23 22:32   ` Romain Beauxis
2024-02-23 22:57     ` Marton Balint [this message]
2024-02-24  0:01     ` James Almer
2024-02-25  1:27 ` Michael Niedermayer
2024-02-28  2:29   ` Romain Beauxis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1a03ad0b-525a-74e6-7ef5-346d455a72e3@passwd.hu \
    --to=cus@passwd.hu \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git