The relocation hack broke debugging on mingw-w64 when using gdb. This
makes the reloc hack dependent on --disable-debug so it's still enabled
for release builds.
This is simply an immediate fix for the issue of broken debugging, we
should probably still look at the possibility of reverting it outright
if it proves to be more trouble than it's worth. For now keeping it
enabled for release builds is a reasonable trade off.
Signed-off-by: Alex Smith <theryuu@warpsharp.info>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Clamp scalefactors by coef2minsf to avoid undefined behavior
caused by signed integer overflow. It also avoids clipping of
coefficients so it should avoid artifacts as well, on very
rare corner cases.
Seems like clang might be miscompiling it and causing a signed integer overflow,
making a FATE test fail.
Doesn't seem to affect performance, it only runs on the ESC codebook.
Reviewed-by: Claudio Freire <klaussfreire@gmail.com>
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Otherwise probing and stream analisys will report a correct coded size
but an empty visible size.
Approved by: kieran
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously, ff_h264_idct_add_neon (originally in the arm version) used
a non-regular transpose in order to be able to use more instructions
that deal with registers as 128 bit register pairs. The aarch64
translation doesn't do it to the same extent, but brought along the
same structure since it was a straight translation.
This reshuffles ff_h264_idct_add_neon, bringing it closer to
the C implementation, making the transpose_4x4H macro do a regular
transpose, usable for other algorithms as well.
Previously, the third and fourth output from transpose_4x4H were
swapped, and prior to cc29d96d5a, the same inputs as well. In
addition to just swapping the outputs, also renumber the intermediate
registers for better readability (making the register order match
transpose_4x8B).
This runs with the same number of cycles as before.
Signed-off-by: Martin Storsjö <martin@martin.st>
Note some tests need vsync drop to produce exact timestamps, these seem not to
need it. quite likely many more dont need it either, ive not checked beyond finding
one that needs it and the ones which have it removed
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The problem is that the argument 'q' is of the type uint8_t.
According to the JPEG standard, if 1 <= q <= 50, the scale factor
'S' should be 5000 / Q. Because the create_default_qtables() reuses
the variable 'q' to store the result of this calculation, for small
values of q < 19, q wil subsequently overflow and give wrong results
in the calculated quantization tables.
Instead, use a new variable 'S' (same name as in RFC2435) with the
proper range to store the result of the division.
Signed-off-by: Martin Storsjö <martin@martin.st>
