This should make it easier to catch problems where some of those
pointers are used uninitialized, since reading from NULL should always
crash, while random numbers from stack can turn out to be valid
pointers, so random memory may be silently overwritten.

If it was set before then we can end up trying to decode a slice without
a valid slice header, which can lead to invalid memory access.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

The code cannot handle there being none, but that should not happen for
valid files.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

It is a public function, it must not assert on its parameters.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

It has been checking the number of bits in the offset instead of the
actual offset.

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC:libav-stable@libav.org

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

And remove all the circular inclusions of avutil.h while at it.

Make much easier debugging.

Drop references to the doxy image gradients and style a the code blocks to
keep the whitespace and indent properly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Green on blue was not exactly optimal.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This is a more sensible place for these macros.

Certain softwares get badly confused.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This avoids false positive enabling of w32threads if explicitly
requested on the command line, but dependencies are missing.

Introduced by 28243b0d

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>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

q4-q7/d8-d15 are supposed to not be clobbered by the callee.

CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Bitstreams conforming to the spec should not use profiles not defined
in it.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Also store a few PTL flags which were skipped before
Signed-off-by: Anton Khirnov <anton@khirnov.net>

According to the spec, the value of XXX_reserved_zero_44bits should be
ignored, so don't report an error when it's not zero.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Still assume the size value is right in non-explode mode.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This function is encoding-only.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Apply David Conrad's old patch to the modern codebase.

http://ffmpeg.org/pipermail/ffmpeg-devel/2009-April/059877.htmlSigned-off-by: Martin Storsjö <martin@martin.st>

For:

ff_vc1_inv_trans_{8,4}x{8,4}_{dc_,}neon
ff_put_pixels8x8_neon
ff_put_vc1_mspel_mc{0,1,2,3}{0,1,2,3}_neon (except for 00)

Based on ARM assembly code in libavcodec/arm by Rob Clark and Mans
Rullgard.
Signed-off-by: Martin Storsjö <martin@martin.st>

Also fix the #endif comment in a few places and #include config.h to
avoid assuming it is #included implicitly.