[FFmpeg-devel] [PATCH 001/281] Add a new channel layout API

[Marton Balint]

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