On Sun, Sep 15, 2024 at 09:09:39PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-09-13 19:48:46) [...] > > > > > > > +#include "libavcodec/internal.h" > > > > > > I dislike this as well. > > > > I am fine with it. > > > > But if you dont, then maybe you can suggest another way to check > > for the number that we support. > > My second objection, in case it is not clear, is to libavformat > including libavcodec internal headers that define libavcodec internal > structures. That is a slippery slope that easily leads to people > actually accessing those internal structures. >
> But also the number 512 is entirely arbitrary, and if we decide to > arbitrarily restrict the channel count everywhere then it should be done > at the level of AVChannelLayout. E.g. by making nb_channels and uint8 or > uint16, and/or adding the check to av_channel_layout_check(). Now that this specific issue is fixed by james patch. Would you agree that the more general issue of "something" allocating and or processing a large number of channels can be checked for ? And that the constant would then of course be moved to libavutil thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment.
signature.asc
Description: PGP signature
_______________________________________________ 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".
