On 2/16/2024 7:42 PM, Marton Balint wrote:
On Thu, 15 Feb 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-02-13 21:27:34)
On Tue, 13 Feb 2024, James Almer wrote:
On 2/12/2024 6:15 PM, Marton Balint wrote:
Signed-off-by: Marton Balint <c...@passwd.hu>
---
libavutil/channel_layout.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index b8bff6f365..db0c005e87 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -146,6 +146,10 @@ enum AVChannelOrder {
* as defined in AmbiX format $ 2.1.
*/
AV_CHANNEL_ORDER_AMBISONIC,
+ /**
+ * Number of channel orders, not part of ABI/API
+ */
+ AV_CHANNEL_ORDER_NB
};
Is it worth adding this to a public header just to limit a loop in a
test? A
loop that fwiw still depends on an array that needs to be updated
with more
names if you add new orders.
Several other enums also have this. So API consistency can be considered
a more important factor.
I'd be concerned that many callers don't undertand the implications of
"not part of the ABI".
Maybe we should rename all of them to FF_ prefix to make it more clear
callers should not use these?
I think this is a good idea. So is it OK to apply this if I change the
prefix to FF?
I wont oppose to it.
_______________________________________________
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".
