[FFmpeg-devel] [PATCH 001/279] Add a new channel layout API

[Lynne]

8 Dec 2021, 13:19 by anton at khirnov.net:

> Quoting Marton Balint (2021-12-08 11:55:37)
>
>>
>>
>> On Wed, 8 Dec 2021, Lynne wrote:
>>
>> > 8 Dec 2021, 11:06 by cus at passwd.hu:
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >>> 8 Dec 2021, 10:22 by h.leppkes at gmail.com:
>> >>>
>> >>>> On Wed, Dec 8, 2021 at 10:14 AM Lynne <dev at lynne.ee> wrote:
>> >>>>
>> >>>>>
>> >>>>> 8 Dec 2021, 02:06 by jamrial at gmail.com:
>> >>>>>
>> >>>>>>
>> >>>>>> +enum AVChannel {
>> >>>>>> +    ///< Invalid channel index
>> >>>>>> +    AV_CHAN_NONE = -1,
>> >>>>>> +    AV_CHAN_FRONT_LEFT,
>> >>>>>>
>> >>>>>
>> >>>>> No, not the pixfmt mistake again. Set AV_CHAN_NONE to 0,
>> >>>>> the rest can follow. Or keep AV_CHAN_NONE to -1
>> >>>>> and add a new AV_CHAN_UNSPECIFIED as 0.
>> >>>>>
>> >>>>
>> >>>> Care to elaborate on the reasons of this opinion? Using -1 as invalid
>> >>>> and 0...x as valid entries seems quite reasonable to me.
>> >>>>
>> >>>
>> >>> Zero-initialization. I've had issues in the past telling
>> >>> YUV420P from <uninitialized>.
>> >>>
>> >>
>> >> It is convenient to be able to set the channel layout mask by a simple byte shift of the ID-s.
>> >>
>> >> AV_CH_FRONT_LEFT = 1 << AV_CHAN_FRONT_LEFT.
>> >>
>> >> So I'd say that is the reason that it is designed that way, because this way existing channel layout masks can be kept without breaking ABI.
>> >>
>> >
>> > Those can be set with offsets, e.g.
>> > AV_CH_FRONT_LEFT = 1 << (AV_CHAN_FRONT_LEFT - 2).
>>
>> Well, I find this less fortunate then the need to initialize NONE to -1...
>>
>> > I'd like to not have weird values in enums because the old
>> > API, just being deprecated, must have its way and can't deal
>> > with an offset.
>>
>> AV_CH_FRONT_LEFT and similar is not deprecated, these are still used for 
>> the native channel order which is still using a mask.
>>
>
> Yes, the direct mapping between channel indices and WAVEFORMATEXTENSIBLE
> values is a design goal here, just as it was in the old API.
>
> I also belive that the initialization issue of pixel/sample formats is
> less of a problem here, since you rarely need to store actual channel
> ids. So IMO retaining channel index compatibility is more important.
>

That's not a goal, it's anti-goal, and a cause for hysterical raisin
picking in the future.
Having an instantly debuggable structure rather than one that
makes you question your sanity is much more important than
some compatibility few care about, apart from some users who
don't even use it but think it's 'neat' and nothing more.