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.
Regards,
Marton
_______________________________________________
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".
