aboutsummaryrefslogtreecommitdiffstats
path: root/tests/fate/qtrle.mak
diff options
context:
space:
mode:
authorAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2020-01-22 00:55:22 +0100
committerAndreas Rheinhardt <andreas.rheinhardt@outlook.com>2022-10-19 13:48:31 +0200
commit30e1f5ec77530fad053730a2ffd10b8286420899 (patch)
tree3a69d4d07bdd5f4dfb6c9a0f2e476016c1c87016 /tests/fate/qtrle.mak
parentb9058765d7422bb801af0e67fb58ba47e523f831 (diff)
downloadffmpeg-30e1f5ec77530fad053730a2ffd10b8286420899.tar.gz
avcodec/startcode: Avoid unaligned accesses
Up until now, ff_startcode_find_candidate_c() simply casts an uint8_t* to uint64_t*/uint32_t* to read 64/32 bits at a time in case HAVE_FAST_UNALIGNED is true. Yet this ignores the alignment requirement of these types as well as effective type rules of the C standard. This commit therefore replaces these direct accesses with AV_RN64/32; this also improves readability. UBSan reported these unaligned accesses which happened in 233 FATE-tests involving H.264 and VC-1 (this has also been reported in tickets #8138 and #8485); these tests are fixed by this commit. The output of GCC with -O3 is unchanged for aarch64, loongarch, ppc and x64 (as well as for arches like alpha for which HAVE_FAST_UNALIGNED is never true in the first place). There was only a slight difference for mips and arm. I don't know about the speed impact of them. Reviewed-by: Anton Khirnov <anton@khirnov.net> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Diffstat (limited to 'tests/fate/qtrle.mak')
0 files changed, 0 insertions, 0 deletions