8 Dec 2021, 11:06 by [email protected]: > > > On Wed, 8 Dec 2021, Lynne wrote: > >> 8 Dec 2021, 10:22 by [email protected]: >> >>> On Wed, Dec 8, 2021 at 10:14 AM Lynne <[email protected]> wrote: >>> >>>> >>>> 8 Dec 2021, 02:06 by [email protected]: >>>> >>>>> >>>>> +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 [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
