On Wed, Dec 8, 2021 at 1:54 PM Lynne <d...@lynne.ee> wrote: > > 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.
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. - Hendrik _______________________________________________ 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".