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>