All versions of MSVC that support C11 (namely >= v19.27)
also support the restrict keyword, therefore av_restrict
is no longer necessary since 75697836b1.
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
h_subpel_filters_inner[i] and h_subpel_filters_outer[i / 2]
belong together and the former allows the range 0..6,
so the latter needs to support 0..3. But it has only three
elements. Add another one.
The value for the last element has been guesstimated
from subpel_filters in libavcodec/vp8dsp.c.
This is also intended to fix FATE-failures with UBSan here:
https://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is accessed via AV_RN64A in ff_simple_idct_put_int32_10bit().
Should fix the UBSan failures in the mpeg4-simple-studio-profile
test here:
https://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Reviewed-by: Kieran Kunhya <kierank@obe.tv>
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
HAVE_FAST_UNALIGNED being true does not imply that
one can simply read from any pointer via *(long*).
It is undefined behaviour in case the pointer is not
sufficiently aligned; and even if it is, it is (likely)
a violation of the effective-type rules. Fix both
of these by using the appropriate AV_[RW]N macros.
Also, the current code used sizeof(long) as if this
were the CPU's native arithmetic size, but this is
not true on 64bit Windows. This has been fixed, too.
This affected huffyuv FATE-tests.
Tested-by: Sean McGovern <gseanmcg@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
They are incorrect according to [1]. They also share keys with valid
entries, so that it is unspecified which entry bsearch returns
in this case. Fix this by removing the incorrect values.
[1]: https://www.earthdata.nasa.gov/s3fs-public/imported/19-008r4.pdf
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Instead store all the strings in one continugous string
(with internal \0) and use offsets to access the actual
substrings. This replaces the pointers to the strings
and therefore avoids relocations (and on x64, it actually
shrinks TiffGeoTagNameType by reusing padding to store
the offset field).
This saves 720B of .data.rel.ro and 1080B of .rela.dyn
(containing the relocation records) here while increasing
.rodata by 384B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This simplifies the code for checking the output, and can print
the failing output (including a map of matching/mismatching
elements) if checkasm is run with the -v/--verbose option.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Previously it only checked half the output in 8 bit per pixel mode,
as the output actually is 16 bit elements here.
Signed-off-by: J. Dekker <jdek@itanimul.li>
The first 32 elements of each row were correct, while the
last 16 were scrambled.
This hasn't been noticed, because the checkasm test erroneously
only checked half of the output (for 8 bit functions), and
apparently none of the samples as part of "fate-hevc" seem to
trigger this specific function.
Signed-off-by: J. Dekker <jdek@itanimul.li>
Muxing multiple streams to raw files is allowed but the packets are
interleaved, so the output is dependant of packet size.
Signed-off-by: Marton Balint <cus@passwd.hu>
The samples I found all have 2000 sample packets, and by forcing the packet
size with a bsf we could automagically make muxing work for packets containing
more than 3640 samples.
Signed-off-by: Marton Balint <cus@passwd.hu>
