Manually load registers to avoid using 8 registers on x86_32 with
compilers that do not align the stack (e.g. MSVC).
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Accept the buffer size in bytes and check for overflow before passing
the value in bits to init_get_bits.

Fix an undefined behaviour and make the function return a proper
error in case of overflow.

CC: libav-stable@libav.org

Freeing it in av_destruct_packet(), as is done currently, would mean
that we allow it to be allocated with other means. But that would make
av_packet_new_side_data() unsafe.

Side data is not expected to be large, so copying it if required
shouldn't be a problem.

Codec timebase is supposed to be set by decoders only.

v4l2_read_header() does no cleanup, so it can return directly, without
any need for goto.

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

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

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

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

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

Previously, we always signalled a zero time since the last RTCP
SR, which is dubious.

The code also suggested that this would be the difference in
RTP NTP time units (32.32 fixed point), while it actually is
in in 1/65536 second units. (RFC 3550 section 6.4.1)
Signed-off-by: Martin Storsjö <martin@martin.st>

This brings back some code that was added originally in 4a6cc061
but never was used, and was removed as unused in 4cc843fa. The
code is updated to actually work and is tested to return sane
values.
Signed-off-by: Martin Storsjö <martin@martin.st>

The base_seq variable is set to first_seq - 1 (in
rtp_init_sequence), so no + 1 is needed here.

This avoids reporting 1 lost packet from the start.
Signed-off-by: Martin Storsjö <martin@martin.st>

Also rename the test to reflect that the video track is Theora, not VP3.

Also fix a lavu version typo in APIchanges.

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

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

The question can be answered: No, we do not know the initial sequence
number from the SDP. In certain cases, it can be known from the
RTP-Info response header in RTSP though. (In that case, we use it as
timestamp origin, but not for rtp receiver statistics.)
Signed-off-by: Martin Storsjö <martin@martin.st>

It is unclear what the bug exactly was and if it ever was fixed,
and we don't even support decoding via faad any longer. The
comment has been present since d0deedcb in 2006.
Signed-off-by: Martin Storsjö <martin@martin.st>

One of them is renamed now, but mentioning it by name serves
no purpose here.  The other table mentioned ceased to exist
under that name in 4934884a in 2006.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

Remove leftover debug comments, fix brace placement and
add whitespace, remove unnecessary and weirdly placed braces.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Signed-off-by: Martin Storsjö <martin@martin.st>

Prevent the crash on fuzzed files as reported in bug 63.

Handle pred_flag parameter not given to get_mvdata_interlaced()
Signed-off-by: Vladimir Pantelic <vladoman@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Previously, for broken frames, we only returned the first partition
of the frame (we would append all the received packets to the packet
buffer, then set pkt->size to the size of the first partition, since
the rest of the frame could have lost data inbetween) - now instead
return the full buffered data we have, but don't append anything more
to the buffer after the lost packet discontinuity. Decoding the
truncated packet should hopefully get better quality than trimming out
everything after the first partition.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

This is required by RFC 3550 (section 6.5):

   The list of items in each chunk MUST be terminated by one or more
   null octets, the first of which is interpreted as an item type of
   zero to denote the end of the list.

This was implicitly added as padding before, unless the host name
length matched up so no padding was added.

This makes wireshark parse the packets properly if other RTCP items
are appended to the same packet.
Signed-off-by: Martin Storsjö <martin@martin.st>