Le keskiviikkona 12. kesäkuuta 2024, 22.39.49 EEST James Almer a écrit : > >> These are not padded, and unless I'm reading this wrong, an asm > >> implementation loading say 16 bytes at a time will overread/write in > >> dct_unquantize_intra (which offsets block by 1). > > > > AFAIU, there is no padding per se, but the block buffer size is always > > exactly 64 elements, regardless of the number of coeffs, hence this code. > > The old NEON intrinsic code seems to assume the block is a multiple of 8 > > elements, and the tail can be overwritten safely (hence not checking in > > memcmp()). > > > > I have a feeling that I am not grasping the implications of you comment > > here. > An asm function loading 16 bytes at a time from block[1] onwards for > intra may end up reading two bytes more than available at the end of the > 128 byte wide buffer.
Wouldn't that be a bug in the assembler function? Do you mean that checkasm should add padding to check against overwrites? The whole point of separating inter and intra was to preserve alignment for those instruction set extensions that want it (C and RVV couldn't care less). -- レミ・デニ-クールモン http://www.remlab.net/ _______________________________________________ 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".
