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>

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.html

Signed-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>

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>

Tables are always allocated now with sufficient space for either progressive
or interlaced content. The alternative would be to detect a change
and reallocate.

This fixes decoding of a sample.

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

Directly set the fields when necessary.

Directly set the fields when necessary.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Useful for reading png images from a pipe.

This fixes decoding, broken since 7e35037.

This is similar to what was done for the normal mp3 decoder in
f4a86bc9.

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

Also bump libavcodec micro and add an APIchanges entry saying that
av_frame_* should now be used instead of the lavc AVFrame functions.

This is a temporary workaround to allow deprecating
avcodec_get_frame_defaults(). The proper solution will be using a
properly allocated AVFrame in Picture.

avcodec_decode_audio4() resets the frame itself.

This is a temporary workaround to allow deprecating
avcodec_get_frame_defaults(). The proper solution will be using a
properly allocated AVFrame in Picture.

ff_mpeg_unref_picture() already resets the frame.

avcodec_get_frame_defaults() will be deprecated.

av_frame_free() should be used instead.

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

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

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

Fix writing over the end

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Addresses: CVE-2013-0845

Simplifies host/target libc detection splitting.

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

The a52 spec suggests that "partial compression" should scale the
drc value in this manner.

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

Use only proper AVFrame API (no assigning of whole frames, since that
hardcodes sizeof(AVFrame) into lavc).

Make a copy of the side data, so the caller can use av_frame_unref/free
on non-refcounted frames, eliminating the need for
avcodec_get_frame_defaults()/avcodec_free_frame().

Not just on failure. This is the same thing that is done in the audio
path and should prevent leaks in decoders that allocate a frame, but
then end up not writing into it.

av_frame_unref() works fine on unallocated frames.

data[0] may be NULL for valid frames with hwaccel pixel formats.

All decoders should now handle it properly.

Remove the extended_data workaround, all decoders should now handle this
properly.

The (optimized) functions are used nowhere else.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Tim Walker <tdskywalker@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The vlc reader cannot handle 0-bit huffman codes. For most
situations WebP uses the "simple" huffman coding for this case,
but that will only handle symbols up to 255. For the LZ77 distance
codes, larger symbol values are needed, so it can happen in rare
cases that a normal huffman table is used that only has a single
symbol.