Return the correct number of consumed bytes and set *data_size = 0.
Returned size is 1 too small, leading to that 1 byte being read as the next
frame, which results in an extra blank frame at the beginning of the stream.

get_ue_golomb_long() is only tested for values up to 2^15 - 2 since
we can not write larger values.
Silence the test on success and return a non-zero value on error.
Use an heap scratch buffer instead of large stack buffer.
Remove unneeded includes.

fixes the tests on big-endian systems

Fixes fate-targa-conformance-CCM8 and fate-targa-conformance-UCM8.

Based on a patch by Oana Stratulat <oanaandreeastratulat@gmail.com>

(Does not attempt to decode percetual audio data inside.)
Code coverage: libavformat/xwma.c: 3% -> 75%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

(Don't attempt to decode JPEG data.)
Code coverage: libavformat/smjpeg.c: 0% -> 69%
libavcodec/adpcm.c: 0% -> 10% (fresh run); 92.4% -> 93% following a FATE run
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Does not attempt to decode perceptual codecs inside.
Code coverage: libavformat/wtv.c: 0% -> 71%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

Code coverage:
libavformat/xmv.c: 3% -> 91%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Code coverage:
libavcodec/bmv.c: 0% -> 75%
libavformat/bmv.c: 0% -> 85%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Code coverage:
libavcodec/indeo4.c: 0% -> 78%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

The previous sample used for this test only contained type 0 frames.
Replace it with a sample that also features type 1 frames.
Code coverage:
libavcodec/xxan.c: 72% -> 89%
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Change the recent h264_mp4toannexb bitstream filter test to output to an elementary stream rather than a program stream.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

Palette is as supposed in native endianness. Converting the pal8 output
to rgb24 is thus necessary for identical CRCs on big and little endian
systems.

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

This test uses an existing FATE sample (h264/interlaced_crop.mp4).
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

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

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

The sample has an incomplete last frame.  Decoding it is pointless.
The garbage produced was changed by the bitstream reader now
protecting against over-reads.
Signed-off-by: Mans Rullgard <mans@mansr.com>

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

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Diego Biurrun <diego@biurrun.de>

This patch is a generalization of what Michael Niedermayer
fixed in a single case.

The wmv8-drm fate test had been updated accordingly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

It's not supposed to be set outside of lavc. Set r_frame_rate and
avg_frame_rate instead.

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

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Also check for sufficient packet size.

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

AVFMT_NOTIMESTAMPS for crc, as it ignores the timestamps.
AVFMT_VARIABLE_FPS for framecrc, as it prints dts.

Many FATE changes, because avconv is no longer duplicating frames in
those tests.
Also added -vsync 0 for some tests to prevent avconv from dropping
frames until it can be fixed more properly.

enable CODEC_CAP_DELAY to flush any remaining frames in the buffer.

Stop decoding when the FN_QUIT command is found so that a trailing seek table
isn't decoded as a normal frame.

decode all channels in the same call to avcodec_decode_audio3() so that
decoding will not stop after the first channel of the last frame.

Updated FATE reference. More valid audio is now decoded.

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

The size check must be updated to take into account both manners
in which v_data_size might be set.
Signed-off-by: Mans Rullgard <mans@mansr.com>

The pixel format is not known until the frame header is parsed.
Guessing it here only causes trouble for the caller if the guess
turns out to be wrong (and actually causes very wrong output by
avconv/avplay).
Signed-off-by: Mans Rullgard <mans@mansr.com>