8 Dec 2021, 13:19 by an...@khirnov.net:
> Quoting Marton Balint (2021-12-08 11:55:37)
>
>>
>>
>> On Wed, 8 Dec 2021, Lynne wrote:
>>
>> > 8 Dec 2021, 11:06 by c...@passwd.hu:
>> >
>> >>
>> >>
>> >> On Wed, 8 Dec 2021, Lynne wrote:
>> >>
>> >>> 8 Dec 2021, 10:22 by h.lepp...@gmail.com:
>> >>>
>> >>>> On Wed, Dec 8, 2021 at 10:14 AM Lynne <d...@lynne.ee> wrote:
>> >>>>
>> >>>>>
>> >>>>> 8 Dec 2021, 02:06 by jamr...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
