From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 54D1B42486 for ; Mon, 17 Jan 2022 20:18:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5C7DB68B063; Mon, 17 Jan 2022 22:18:27 +0200 (EET) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 3EA3E68A51B for ; Mon, 17 Jan 2022 22:18:21 +0200 (EET) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id 98A9EE6059 for ; Mon, 17 Jan 2022 21:18:20 +0100 (CET) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0b55KZSFyMr for ; Mon, 17 Jan 2022 21:18:19 +0100 (CET) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id B71A5E604F for ; Mon, 17 Jan 2022 21:18:18 +0100 (CET) Date: Mon, 17 Jan 2022 21:18:18 +0100 (CET) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: <38842fd9-8a30-5ff0-e48c-4a70d405790c@gmail.com> Message-ID: References: <20220113015101.4-1-jamrial@gmail.com> <20220113015101.4-2-jamrial@gmail.com> <38842fd9-8a30-5ff0-e48c-4a70d405790c@gmail.com> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 001/281] Add a new channel layout API X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Mon, 17 Jan 2022, James Almer wrote: > > > You're still thinking there's a distinction, when i already told you that > there is none. I added the name field because people wanted to give non > standard channel names, and maybe also change the standard ones too. It's not > a label to go alongside a designation, it's *a* name. > There are about 20 channels that have a standard name from waveformat and > extensions, while the rest lack one. You can obviously have a non standard > speaker setup with 50 channels, and all those extra speakers can surely have > a name based on their position (Say, RTFC, to refer to "right of top front > center"), so the field lets you give it to them if that's convenient for you > and you want a pretty print output of the layout without seeing things like > USR49. That's it. OK, but shouldn't the user be able to specify if it means a builtin name or a custom name when specifying a channel name? That is why I suggested some additinal syntax for custom names in av_channel_layout_index_from_string() and av_channel_layout_channel_from_string(). Like "FL" is a builtin name, "@name" is a custom name. > > Yes, av_channel_layout_from_string() will not be able to parse the output of > av_channel_layout_from_describe() if you gave channels a custom name, since > they are specifically from that other layout. There's no way around that, as > we can't make describe() output some string that from_string() can interpret > for those because then describe() will be useless for printing the layout for > human readability purposes. > It is in fact a good reason to either remove the name field or stop making > these helpers look at it, since describe() is meant to create strings > from_string() can parse. > > I personally would do just that and keep the opaque fields alone. Otherwise > I'll make the helpers stop looking at it, since after your request, non > standard channels can be addressed as USR#, so you can create layout from > strings with them just fine. Removing the custom names is fine with me. Maybe it's a compromise nobody is particularly happy about. 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".