[FFmpeg-devel] [PATCH 2/5] avutil/channel_layout: add AV_CHANNEL_ORDER_NB
James Almer
jamrial at gmail.com
Sat Feb 17 00:44:21 EET 2024
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 <cus at 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.
More information about the ffmpeg-devel
mailing list