User data is usually coded before slice data. That means the frame
the user data belongs to is not available while parsing the user data.
The stereo3D side data has to use the same indirection over the private
context as pan scan information and A53 captions.

Bug-Id:632

Also adjust header #include order and some comments.
Signed-off-by: Diego Biurrun <diego@biurrun.de>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Add checks to the fast functions used with CODEC_FLAGS2_FAST and move
the check for all other functions to before the invalid memory is
accessed. Fixes https://trac.videolan.org/vlc/ticket/9713 with
CODEC_FLAGS2_FAST.

CC: libav-stable@libav.org

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

XvMC has long ago been superseded by newer acceleration APIs, such as
VDPAU, and few downstreams still support it. Furthermore XvMC is not
implemented within the hwaccel framework, but requires its own specific
code in the MPEG-1/2 decoder, which is a maintenance burden.

It is always called by passing fields from an AVCodecContext.

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

Slice threading does not work with hardware acceleration, as decoding
is per-picture.  This fixes Bugzilla #542.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

The decoder did not start predicted frames with missing references but
called the end of frame handling on them anyway. This caused an
assertion in the VA API HW accelorator since it tried to render a
picture with uninitialized buffers.

Also move the declaration to internal.h, and add restrict qualifiers
to the declaration (as in the implementation).
Signed-off-by: Martin Storsjö <martin@martin.st>

The total frame size is a combination of the 12 bits in the sequence
header and 2 more bits in the the sequence extension. While the
specification explicitly forbids the dimensions from the sequence header
from being 0 (thus ruling out multiples of 4096), such videos
apparrently exist in the wild so we should attempt to decode them.

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

Fixes Bug 416.

Not all hwaccels implement all codecs, so using one single list for
multiple such codecs means some codecs will be represented in the list,
even though they don't actually handle that codec. Copying specific
lists in each codec fixes that.
Signed-off-by: Martin Storsjö <martin@martin.st>

Split out dependency on MpegEncContext.

It does not help as an abstraction and adds dsputil dependencies.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

Fixes CVE-2012-2803.

CC: libav-stable@libav.org

Since we can't know which stride a custom get_buffer() implementation is
going to use we have to allocate this scratch buffers after the linesize
is known. It was pretty safe for 8 bit per pixel pixel formats since we
always allocated memory for up to 16 bits per pixel. It broke hoever
with cmdutis.c's alloc_buffer() and high pixel bit depth since it
allocated larger edges than mpegvideo expected.

Fixes fuzzed sample nasa-8s2.ts_s244342.

This table doesn't need to be shared with libavformat any longer.
Add mpeg12 to the name to make it less ambiguous, while renaming it.
Signed-off-by: Martin Storsjö <martin@martin.st>

It is got_output, not data_size.

Avoids a forward declaration of decode_chunks().

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This feature is complex, of questionable utility, and slows down
normal decoding.
Signed-off-by: Mans Rullgard <mans@mansr.com>

If user opted to present fields as they come, then the first field
picture needs to be submitted to the HW for decoding. In particular,
this fixes MPEG-2 decoding of interlaced streams.

Tested on Intel Cedar Trail, Sandy Bridge and Ivy Bridge platforms.
Someone reported on the ffmpeg-devel@ list this also works on DXVA
(Windows) and other Linux platforms (NVIDIA, through the VA wrapper).

This also means a similar patch to non-hwaccel VDPAU may be necessary.

Note: I believe the SLICE_FLAG_ALLOW_FIELD is useless since the first
field shall always be submitted to the HW anyway. Nobody uses HW accels
(dxva, vaapi, vdpau, etc.) without that flag though.
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>
Signed-off-by: Martin Storsjö <martin@martin.st>