Martin Storsjö [Wed, 9 Jan 2013 16:56:17 +0000 (18:56 +0200)]
rtpdec: Send a valid "delay since SR" value in the RTCP RR packets
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)
Martin Storsjö [Thu, 10 Jan 2013 14:35:11 +0000 (16:35 +0200)]
rtpdec: Calculate and report packet reception jitter
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.
Martin Storsjö [Fri, 11 Jan 2013 13:07:51 +0000 (15:07 +0200)]
rtpdec: Remove a useless todo comment
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.)
Martin Storsjö [Fri, 11 Jan 2013 12:53:58 +0000 (14:53 +0200)]
rtsp: Remove an outdated comment
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.
Martin Storsjö [Fri, 11 Jan 2013 12:47:10 +0000 (14:47 +0200)]
rtsp: Remove references to weirdly named variables in other files
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 4934884a1 in 2006.
Martin Storsjö [Wed, 9 Jan 2013 12:25:59 +0000 (14:25 +0200)]
rtpdec_vp8: Don't trim too much data from broken frames
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.
Martin Storsjö [Wed, 9 Jan 2013 17:41:21 +0000 (19:41 +0200)]
rtpdec: Add a terminating null byte at the end of the SDES/CNAME
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.
Martin Storsjö [Tue, 8 Jan 2013 21:21:15 +0000 (23:21 +0200)]
rtpdec_vp8: Mark broken packets with AV_PKT_FLAG_CORRUPT
This allows the caller to either include them (and get more packets
decoded, but possibly some nonperfect frames), or discard them (by
setting fflags=discardcorrupt).
Justin Ruggles [Sun, 30 Dec 2012 22:00:00 +0000 (17:00 -0500)]
oggenc: add a page_duration option and deprecate the pagesize option
This uses page duration instead of byte size to determine when to buffer
the page. Also, it tries to avoid continued pages by buffering the current
page if there are already packets in the page and adding the next packet
would require it to be continued on a new page. This can improve seeking
performance.
The default page duration is 1 second, which is much saner than filling
all page segments by default.
Martin Storsjö [Tue, 11 Dec 2012 13:59:24 +0000 (15:59 +0200)]
rtpdec: Support sending RTCP feedback packets
This sends NACK for missed packets and PLI (picture loss indication)
if a depacketizer indicates that it needs a new keyframe, according
to RFC 4585.
This is only enabled if the SDP indicated that feedback is supported
(via the AVPF or SAVPF profile names).
The feedback packets are throttled to a certain maximum interval
(currently 250 ms) to make sure the feedback packets don't eat up
too much bandwidth (which might be counterproductive). The RFC
specifies a more elaborate feedback packet scheduling.
The feedback packets are currently sent independently from normal
RTCP RR packets, which is not totally spec compliant, but works
fine in the environments I've tested it in. (RFC 5506 allows this,
but requires a SDP attribute for enabling it.)
Martin Storsjö [Mon, 7 Jan 2013 19:42:46 +0000 (21:42 +0200)]
rtpdec_vp8: Make sure the previous packet is returned
This is a bug from c7d4de3d73 - if the previous frame wasn't
returned yet (due to missing the final packets), but we have
enough data of it to return the first partition, we write that into
pkt and set returned_old_frame. That commit forgot returning 0 for
the case where this current packet didn't have the end_packet flag
set.
Martin Storsjö [Mon, 7 Jan 2013 16:39:04 +0000 (18:39 +0200)]
rtsp: Recheck the reordering queue if getting a new packet
If we timed out and consumed a packet from the reordering queue,
but didn't return a packet to the caller, recheck the queue status.
Otherwise, we could end up in an infinite loop, trying to consume
a queued packet that has already been consumed.
CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
Justin Ruggles [Fri, 28 Dec 2012 21:58:55 +0000 (16:58 -0500)]
lavr: mix: reduce the mixing matrix when possible
If the matrix results in an output channel not getting a contribution
from any input channel and the corresponding input channel does not
contribute to any outputs, we can skip the channel during mixing and
silence it after mixing.
If the matrix results in an input channel not contributing to any output
channels and it is not in the output mix, or if the input channel only
contributes fully to the same output channel, we can skip the channel
during mixing.
If the matrix results in an output channel only getting full
contribution from the corresponding input channel and that input channel
does not contribute to any other output channels, we can skip the
channel during mixing.
If a bug exists on the tracker, its ID should always be included
in fix messages.
Also, any relevant bug fixes should be CC'd to libav-stable, so
we can actually track what needs to be backported, instead of
just randomly combing the git history and old CVEs.