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@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
_______________________________________________
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".
