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".
next prev parent 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