The fate reference is updated because the previous test skipped a sample in
each encode() call due each input frame having an odd number of samples.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Decode to the correct output buffer.

Signed-off-by: Martin Storsjö <martin@martin.st>

Also call avcodec_set_dimensions on dimension param change packets.

Signed-off-by: Martin Storsjö <martin@martin.st>

This is in preparation to calling it from avcodec_decode_video2.

Signed-off-by: Martin Storsjö <martin@martin.st>

Fixes null pointer dereferences in fuzzed files found by Oana Stratulat.

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Bug found by: Oana Stratulat

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Prevent invalid reads using bytestream2 functions.
Fixes bug #126.

Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>

Fixes Bug: #190
Chromium Bug: #100543
Related to CVE-2011-3893

Signed-off-by: Reinhard Tartler <siretart@tauware.de>

Fixes --disable-everything --enable-decoder=h264 --disable-optimizations.

The mpeg4 video, H264 and VC-1 parser hold (directly or indirectly)
a MpegEncContext in their private context. Since they do not call the
common mpegvideo init function slice_context_count has explicitly set
to 1.
Prevents a null pointer dereference in the h264 parser and fixes
bug 193.

Prevents null ptr derefence for negative sizes.

4xm decoder while decoding i2 frames can overread the buffer if proper checks
are not made.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Check explicitly if enough bits are left to prevent an infinite loop
when the bitstream buffer is not followed by zero-padding.

Based on patches by Michael Niedermayer <michaelni@gmx.at>.

Fixes a regression introduced in 8b94df0f20.

This fixes an infinite loop in the decoder on specially
crafted files, and fixes bug 151.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This reverts commit 295a7c0238. The
patch breaks decoding of regular files (e.g. fate-4xm-2).

4xm decoder while decoding i2 frames can overread the buffer if proper checks
are not made.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

frame_size is the number of bytes left in the packet, so if we are passing
buf-4 we can safely read frame_size+4 bytes.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The current code doesn't work unless width is an exact multiple of 16.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

This fixes compilation failures related to START_TIMER/STOP_TIMER macros and
-Werror=declaration-after-statement.  START_TIMER declares variables and thus
may not be placed after statements outside of a new block.

For small video dimensions, these calculations of the upper bound
for pixel access may have a negative result. Using an unsigned
comparison to bound a potentially negative value only works if
the greater operand is non-negative. Fixed by doing edge emulation
when the upper bound is probably negative, everywhere that this
pattern appears.

Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

For small video dimensions calculations of the upper bound for pixel
access may result in negative value. Using an unsigned comparison
works only if the greater operand is non-negative. This is fixed by
doing edge emulation explicitly for such conditions.

Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Perform dequantization while decoding coefficients instead of performing it
on the entire coefficients buffer.

Since quantized coefficients are very sparse, this usually causes a small
speedup. Speedup of around 1% on Panda board compared to the removed here
neon code. Global speedup is probably around 3%.

Signed-off-by: Kostya Shishkov <kostya.shishkov@gmail.com>

Fixes hangs if the last packet contains an end-of-sequence NAL unit,
bug 158.

This fixes compilation failures related to START_TIMER/STOP_TIMER macros and
-Werror=declaration-after-statement.  START_TIMER declares variables and thus
may not be placed after statements outside of a new block.

also add more documentation about the header structure

avctx->frame_size is 32, so that is how many samples we process per call.

It is already set by avcodec_alloc_frame().

The previous code ended in multiple different infinite
loops. See stl_ten_1_big.sfd as example with and without zzuf

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Justin Ruggles <justin.ruggles@gmail.com>