You've already forked FFmpeg
mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2026-04-29 12:54:10 +02:00
e7a629049f
Forgotten in70a7df049c. Using the wrong scantable matters for codecs for which both scantables can differ, namely the MPEG-4 decoder and the WMV1/2 codecs. For WMV1 it can lead to wrong output in case the IDCT permutation is FF_IDCT_PERM_PARTTRANS, because in this case the entries of of the intra scantable's raster end are not always <= the corresponding entries of the inter scantable's raster end when the former is initialized via ff_wmv1_scantable[1] and the latter via ff_wmv1_scantable[0]. FF_IDCT_PERM_PARTTRANS is used iff the Neon IDCT is used (for both arm and aarch64).* Said IDCT is not used during FATE, so that this issue went unnoticed. WMV2 uses the same scantables, but uses a custom IDCT which always uses FF_IDCT_PERM_NONE for which the inter_scantable, so that the output is always correct for it. The scantable for MPEG-4 can change mid-stream (for the decoder), but sincec41818dc5donly the intra scantable is updated, so that both scantables can get out of sync. In such a case the unquantize intra functions could unquantize an incorrect number of coefficients. Using raster_end of the wrong scantable can also lead to an unnecessarily large amount of coefficients unquantized. *: FF_IDCT_PERM_SIMPLE and FF_IDCT_PERM_TRANSPOSE would also not work, but they are not used at all by arm and aarch64. Reviewed-by: Martin Storsjö <martin@martin.st> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>