In file libavcodec/x86/dsputil_mmx.c, function ff_put_pixels_clamped_mmx(), there are two assembly code blocks. In the first block (in the unrolled loop), the instructions "movq 8%3, %%mm1 \n\t" etc have problem.
For above instruction, it is clear what the programmer wants: a load from p + 8. But this assembly code doesn’t guarantee that. It only works if the compiler puts p in a register to produce an instruction like this: “movq 8(%edi), %mm1”. During compiler optimization, it is possible that the compiler will be able to constant propagate into p. Suppose p = &x[10000]. Then operand 3 can become 10000(%edi), where %edi holds &x. And the instruction becomes “movq 810000(%edx)”. That is, it will stride by 810000 instead of 8.
This will cause the segmentation fault.
This error was fixed in the second block of the assembly code, but not in the unrolled loop.
How to reproduce:
This error is exposed when we build the ffmpeg using Intel C++ Compiler, IPO+PGO optimization. The ffmpeg was crashed when decoding a mjpeg video.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it would call get_buffer but never release_buffer.
Also use FFSWAP to ensure that the AVFrame is properly initialized
in the next get_buffer (in particular that data[0] is NULL).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Write out the NAL decoding loops in full so that they are easier
to parse for a preprocessor without it having to be aware of macros
or other such things in C code.
This also makes the code more readable.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
This addresses the problem that some HAM pictures were decoded with
complete transparency as described in the 'iff: ANIM suppport ' thread
on ffmpeg-devel. The decoder was already setting alpha correctly for
CMAP palettes, just not HAM palettes.
Set picture type before calling get_buffer.
This allows the DR application to make better decisions.
It also fixes a resource leak in case of missing reference frames
since it would call get_buffer but never release_buffer.
Also use FFSWAP to ensure that the AVFrame is properly initialized
in the next get_buffer (in particular that data[0] is NULL).
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
Convert them to zigzag order, as the rest of them are.
When I was adding support for 10-bit DNxHD, I just copy-pasted the
missing quant matrices from the spec. Now it turns out the existing
matrices in dnxhddata.c were in zigzag order. This resulted in wrong
quantization for 10-bit DNxHD. The attached patch fixes the problem by
converting 10-bit quant matrices to zigzag order.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>