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

[James Almer]

On 1/17/2022 5:18 PM, Marton Balint wrote:
> 
> 
> 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.

I will not remove it. It has its uses even if helpers don't make 
extended use of it at first.

Advanced syntax can be implemented later. See my comments in v4.

> 
> Regards,
> Marton
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".