[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