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

[Lynne]

8 Dec 2021, 14:10 by h.leppkes at gmail.com:

> On Wed, Dec 8, 2021 at 1:54 PM Lynne <dev at lynne.ee> wrote:
>
>>
>> 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.
>>
>
> The old AV_CH_* values are not chosen randomly, they match  the
> WAVEFORMAT channel ordering and bit position, which a lot of formats
> and system use to identify channel layouts - and will continue to do
> so in the future.
> So its hardly just compatibility with FFmpeg from yester-year thats
> being considered here, but the multimedia infrastructure at large.
>

I don't mind AV_CH_ flags using WAVEFORMATEXTENSIBLE,
but I do mind enum AVChannel following those one to one
with no offset. The two are independent, and having
an offset of one or two won't do anything to the flags as
long as that offset is accounted for when the flags are set.