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

Previously, we required the minimum number of bytes required for
the full box. Don't strictly require the astronomical body and additional
notes fields, but do require an altitude field (which currently isn't
parsed). This matches the initial length check at the start of the function
(which doesn't know about the variable length place field).
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 was missed in e1eb0fc9, when ff_interleaved_peek was
changed to include const during the evolution of the patch.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

As long as caller only writes packets using av_interleaved_write_frame
with no manual flushing, this should allow us to always have accurate
durations at the end of fragments, since there should be at least
one queued packet in each stream (except for the stream where the
current packet is being written, but if the muxer itself does the
cutting of fragments, it also has info about the next packet for that
stream).
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 allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.

In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.

When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.

This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.

One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: Martin Storsjö <martin@martin.st>

Use it in av_dump_format() instead of a huge switch case.

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

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

Unless specified, users must use non registered
range for network id
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Use the newly created vlc.h directly instead of including get_bits when needed.
The VLC and RL_VLC_ELEM structures are independent from the bitreader.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

MPEG-4 is the only decoder which uses check_marker().
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Allows emulation to work when dst is equal to src2 as long as the
instruction is commutative, e.g. `addps m0, m1, m0`.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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.