Due to how pixel format conversion is done, they behave the same way
as gray files.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

The first byte contains compression level together with keyframe status.
When a frame is not interpreted correctly, its data is summed to the
reference, and would degrade over time, producing an incorrect result.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

The current sample comes from an older version of the codec, which
supports a single output mode, so rename it accordingly.
Add tests for the new pixel formats.

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

And bump the document version to 4.

Commit ca2f19b9 modified the meaning of
H264SliceContext.gb: it is now initialised at the start of the NAL unit
header, rather than at the start of the slice header.  The VAAPI slice
decoder uses the offset after parsing to determine the offset of the
slice data in the bitstream, so with the changed meaning we no longer
need to add the extra byte to account for the NAL unit header because
it is now included directly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Change log level from warning to debug: the E-AC-3 "core"
substream can be successfully decoded without the additional
and dependent substreams, and their presence is already
indicated via avpriv_request_sample in ff_eac3_parse_header.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

These errors neither prevent nor stop successful decoding
of the E-AC-3 stream's "core", causing avpriv_request_sample
to be called for every single frame in the bitstream.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Previously, with JACK installed, the configure script would enable the
JACK indev; this broke on OS X due to an incomplete pthreads
implementation. Add some simple macros to map libdispatch to pthreads
on OS X.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

The matroska specification now has two elements for it.

For video, frame_number tracks the number of frames sent to the encoder.
So it should be incremented when we submit a frame, not when we get a
packet back.

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

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

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

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

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

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

This is already performed in init_context_frame().

This is assuming that intrax8 has no support for interlacing
Carry over lowdelay value in ff_intrax8_decode_picture.

These values need to be updated with the last macroblock position,
so keep them as pointers.

Helps in decoupling this code from mpegvideo.

Instead of handling the problem inside NAL decoding code, add a higher
level wrapper function. This should be more robust against future
changes (and easier to read).