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-requ...@ffmpeg.org with subject "unsubscribe".
