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