On Mon, Mar 1, 2021 at 3:51 PM Nicolas George <geo...@nsup.org> wrote:
> Guo, Yejun (12021-03-01): > > Hi, glad to hear there's a good solution, could you share a bit of > > code as an example, it would be nice if I could refine my code better > > when possible, thanks. > > The best choice is to go with BoundingBox boxes[], as Andreas pointed, > and see if people who use compilers where it does not work manifest. > Probably they will not, and if they do we can decide if we want to > continue supporting these obsolete compilers. > > The second best choice is to go with BoundingBox boxes[1], if it is not > proven that the compiler can make assumptions that will break the code. > > The third choice would be something like: > > #define BOX(p, i) (((BoundingBox *)&(p)->boxes)[i]) > or similar. But best try to make the best choice work Why not use frame metadata for this? Instead of clumsy structures? > . > > Regards, > > -- > Nicolas George > _______________________________________________ > 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". _______________________________________________ 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".
