[FFmpeg-devel] [PATCH 2/5] avutil/channel_layout: add AV_CHANNEL_ORDER_NB

Marton Balint cus at passwd.hu
Sun Feb 18 01:15:01 EET 2024



On Fri, 16 Feb 2024, James Almer wrote:

> 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.

Ok, changed locally.

Will apply the series soon.

Regards,
Marton


More information about the ffmpeg-devel mailing list