The new code is faster and reuses the previous state in case of
multiple calls.
The previous code could easily end up in near-infinite loops,
if the difference between two clock() calls never was larger than
1.
This makes fate-parseutils finish in finite time when run in wine,
if CryptGenRandom isn't available (which e.g. isn't available if
targeting Windows RT/metro).
Patch originally by Michael Niedermayer but with some modifications
by Martin Storsjö.
Signed-off-by: Martin Storsjö <martin@martin.st>
According to http://doc.iridas.com/index.php?title=LUT_Formats
for 3D textures, the data is also RGB, and ordered in such a way
that the red coordinate changes fastest, then the green coordinate,
and finally, the blue coordinate changes slowest:
Fixes Ticket #3236.
Otherwise the generic code will unref them, which can then result in
last_picture_ptr == current_picture_ptr, which causes deadlocks at least
in rv40.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org
Some older compilers might have particular trouble with them,
and they do not really seem worth it to me.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The constant may change in libavutil but the library may be compiled
against an older version, thus rejecting a value which is otherwise
supported by the new libavutil.
INT_MAX is used here to denote the max allowed value for a pixel format.
The opt-test code is changed to provide a valid reference example.
and setup the bytestream buffer size accordingly
Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7fdcc513cd45_229_12.vmd
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit '6c0e83511705e7f8f5100e7852a1e7fd16aa8877':
doc: fix a coding style error in the developer documentation.
Merged-by: Michael Niedermayer <michaelni@gmx.at>
This fixes an assertion failure and regression and restores previous behaviour
Fixes Ticket3197
An alternative would be to fail hard in this case and refuse to mux such data.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Introduced by 28243b0d35
Intensity compensation is always used once it was encountered, because
v->next_use_ic is never set back to zero.
Reset v->next_use_ic, when resetting v->next_luty/uv.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f7aa4151661_4885_dmbts3.ts
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes use of uninitialized memory
This also avoids the need to check the scanf() return as the subsequent check catches it
Fixes: msan_uninit-mem_7f712e4dc173_7414_nist_ulaw.nist
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Fixes use of uninitialized memory
Fixes: msan_uninit-mem_7f935c3c6c1a_7413_nist_pcms8.nist
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* qatar/master:
fate: Explicitly specify the pixel format for the pngparser test
Conflicts:
tests/fate/image.mak
Merged-by: Michael Niedermayer <michaelni@gmx.at>
The RGB32 pixel format is RGBA/BGRA depending on target
endianness - make sure to convert it to one specific format for
the framecrc tests.
This fixes the pngparser fate test on big endian.
Signed-off-by: Martin Storsjö <martin@martin.st>
Avoids use of uninitialized memory
Fixes: msan_uninit-mem_7f15e1988a6e_2748_RL_420p_ffdirac.drc
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
* commit 'd8fd183683b7495566b7e510a6536ae2efe8dfed':
vc1: Fix mb_height for field pictures
See: 017e234c20
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Since pc.state is populated by shifting in from the end of the
32 bit word, the content within pc.state is already in native endian
and should not be read with the AV_R{L,B} functions.
This was already done correctly for state64 above.
This fixes the fate-corepng test on big endian.
Signed-off-by: Martin Storsjö <martin@martin.st>
openvela-robot