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).
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.
_______________________________________________
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".
