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>

Use the libavutil replacement.

This matches the AVInputFormat.read_packet() API.

Add some additional checks for EOF and print error messages on an incomplete
header or packet.

FATE reference updated for id-cin-video due to the demuxer no longer
returning a partial video packet at EOF.

chunk_size is unsigned 32-bit, but av_get_packet() takes a signed int as the
packet size.

Also, do not allow seek-by-byte, as there is no way to find the next packet
boundary.

Also, use 1 / sample_rate for audio stream time_base.

Avoids using unsupported parameters and signed integer overflows.

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