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

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

timeStampLength, OCRLength and AU_Length have well specified upper
boundaries.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

We still only support one single layer though, but this allows
receiving streams that have this structure present even for
single layer streams.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

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

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

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

This reverts commit 33ac77e8.

It qualifies as a system library.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This uses a new MMAL feature, which limits the number of extra frames
that can be buffered within the decoder. VIDEO_MAX_NUM_CALLBACKS can
be defined as positive or negative number. Positive numbers are
absolute, and can lead to deadlocks if the user underestimates the
number of required buffers. Negative numbers specify the number of extra
buffers, e.g. -1 means no extra buffer, (-1-N) means N extra buffers.

Set a gratuitous default of -11 (N=10). This is much lower than the
firmware default, which appears to be 96.

This is backwards compatible, but needs a symbol only present in newer
firmware headers. (It's an enum item, so it requires a check in
configure.)
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Slight simplification. The result is the same. Also, change the
wording of the message as requested in patch review.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The mmal decoders do not depend on the software decoders.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Fixes apparent mmal_port_disable() freezes in ffmmal_stop_decoder() when
calling ffmmal_decode() with flush semantics a large number of times in
a row.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The assert in ffmmal_stop_decoder() could trigger sometimes. The
packets_buffered counter was indeed not correctly maintained, and
packets were not subtracted from it if they were still in the waiting
queue.

For some reason, this happened especially with VC-1.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

Register mmaldec as mpeg2 decoder. Supporting mpeg2 in mmaldec is just a
matter of setting the correct MMAL_ENCODING on the input port. To ease the
addition of further supported mmal codecs a macro is introduced to generate
the decoder and decoder class structs.
Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

There is no avpriv_atomic_get, instead avpriv_atomic_int_get is to be used for
integers. This fixes building mmaldec.
Signed-off-by: Julian Scheel <julian@jusst.de>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

The original sample was generated with invalid software.

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

And simplify and explain the expression.

Fault introduced in f3fdef10

It is always equal to nb_slice_ctx.

This is more correct and avoids wasting space when frame threading is
used.

This limit is now unnecessary, we can easily support an arbitrary number
of threads.

Those should already be set to the correct values.

In such a case, decode the MBs in parallel without the loop filter, then
execute the filter serially.

The ref2frm array was previously moved to H264SliceContext. That was
incorrect, since it applies to all the slices and should properly be in
H264Context (it did not actually break decoding, since this distinction
only becomes relevant with slice threading and deblocking_filter=1,
which was not implemented before this commit). The ref2frm array is thus
moved back to H264Context.

It is not used for anything internally, just exported in the output
frames. So remove the indirection and set it directly in frame_start().