On 1/19/2022 5:51 PM, Marton Balint wrote:
On Tue, 18 Jan 2022, James Almer wrote:
From: Anton Khirnov <an...@khirnov.net>
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate the old API working with just uint64_t bitmasks.
Expanded and completed by Vittorio Giovara <vittorio.giov...@gmail.com>
and James Almer <jamr...@gmail.com>.
Signed-off-by: Vittorio Giovara <vittorio.giov...@gmail.com>
Signed-off-by: James Almer <jamr...@gmail.com>
---
Changes since last version:
*av_channel_layout_from_string() and av_channel_layout_describe() now
support
a "designation@name" syntax, effectively making both functions reciprocal
when there are custom names in some or all channels.
It's the syntax suggested by Marton and is both extensible if required
and
not too ulgy in human readable output if the string is printed verbatim.
*av_channel_layout_index_from_string() and
av_channel_layout_channel_from_string() also support this syntax now.
I have two suggestions. None of them is actually blocking, but since
they concern public syntax and API it might be better to decide now.
av_channel_layout_index_from_string() without "@" in the string matches
both builtin names (designations) and custom names. I suggest for it to
only match builtin names. If a user wants to match by custom name,
"@name" may be specified without a designation. This keeps the two
namespaces separate.
Ok, look into implementing this.
av_channel_layout_channel_from_string() is an API which is not used in
the codebase. I am not enterely sure about its purpose, so maybe it
should be removed for now, and only added later, if some code actually
needs it.
Since you can set custom names and query them without the designation,
it can be useful as a shortcut for "idx =
av_channel_layout_index_from_string(str) &&
av_channel_layout_channel_from_index(idx)".
If there were no custom names then yeah, there would be no point to it.
Thanks,
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".
