The yasm/nasm preprocessor only checks the first token, which means that
parameters such as `dword [rax]` are treated as identifiers, which is
generally not what we want.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

Those instructions are not commutative since they only change the first
element in the vector and leave the rest unmodified.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

The data field does not necessarily point to the beginning of the
underlying AVBuffer.

CC: libav-stable@libav.org

Many encoders use it. There is also a divide by the timebase lower in
this function, which would crash when it is not set.

Some code blocks use multiple bits of deprecated API.

Avoids unused function/label/variable warnings after the next version bump.

This avoids unused variable warnings after the next version bump.
Also drop a trace level av_log() call that is in the way.

When feeding input RTP packets to the depacketizer via custom IO,
it needs to pick the right stream using the payload type for
RTP packets, and using the SSRC for RTCP packets. If the first
packet is an RTCP packet, we don't (currently) know the SSRC
yet and thus can't pick the right RTP depacketizer to handle it.

By parsing the SSRC attribute in the SDP, we can map initial
RTCP packets to the right stream.
Signed-off-by: Martin Storsjö <martin@martin.st>

It doesn't matter what the actual reason for not returning
an AVPacket was - if we didn't return any packet and we have
the next one queued, parse it immediately. (rtp_parse_queued_packet
always consumes a queued packet if one exists, so there's no risk
for infinite loops.)
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Widen the values from limited to full range and use BT.709 where it
should be used according to the video resolution:

SD is BT.601, HD is BT.709

Default to BT.709 due to most observed HDMV content being HD.

BT.709 coefficients were gathered from the first two parts of BT.709
to BT.2020 conversion guide in ARIB STD-B62 (Pt. 1, Chapter 6.2.2).
They were additionally confirmed by manually calculating values.

This fixes fate-wmv8-intrax8 in certain configurations, e.g.
gcc 4.4.
Signed-off-by: Martin Storsjö <martin@martin.st>

The declarations that this comment referred to were removed
in 2439f2ca - there is no unbuffered IO in this header now.
Signed-off-by: Martin Storsjö <martin@martin.st>

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>