See commit a7829a2a

See commit 9d740127

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

This can only be used if the input data happens to be laid out
exactly correctly.

This might not be supported on all encoders, so only enable it
with an option, but enable it automatically on raspberry pi,
where it is known to be supported.
Signed-off-by: NMartin Storsjö <martin@martin.st>

The raspberry pi uses the alternative API/ABI for OMX; this makes
such builds incompatible with all the normal OpenMAX implementations.
Since this can't easily be detected at configure time (one can
build for raspberry pi's OMX just fine using the generic, pristine
Khronos OpenMAX IL headers, no need for their own extensions),
require a separate configure switch for it instead.

The broadcom host library can't be unloaded once loaded and started;
the deinit function that it provides is a no-op, and after started,
it has got background threads running, so dlclosing it makes it
crash.
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

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

This fixes building on MSVC 2010 and 2012 after d12b5b2f.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This avoids spurious library rebuilds when only the test program
code is changed and simplifies the build system.

Restore alphabetical order in lists, break overly long lines, do some
prettyprinting, add some explanatory section comments, group parts
together that belong together logically.

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

Signed-off-by: NVittorio 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: NVittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: NVittorio 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: NVittorio 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: NLuca 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: NLuca 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: NLuca 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: NLuca 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: NAnton Khirnov <anton@khirnov.net>

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

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

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

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

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