Martin Storsjö [Sat, 20 Oct 2012 20:18:01 +0000 (23:18 +0300)]
rtsp: Support decryption of SRTP signalled via RFC 4568 (SDES)
This only takes care of decrypting incoming packets; the outgoing
RTCP packets are not encrypted. This is enough for some use cases,
and signalling crypto keys for use with outgoing RTCP packets
doesn't fit as simply into the API. If the SDP demuxer is hooked
up with custom IO, the return packets can be encrypted e.g. via the
SRTP protocol.
If the SRTP keys aren't available within the SDP, the decryption
can be handled externally as well (when using custom IO).
Martin Storsjö [Sat, 20 Oct 2012 22:20:35 +0000 (01:20 +0300)]
lavf: Add functions for SRTP decryption/encryption
This supports the AES_CM_128_HMAC_SHA1_80 and
AES_CM_128_HMAC_SHA1_32 cipher suites (from RFC 4568) at the
moment. The main missing features are replay protection (which can be
added later without changing the internal API), and the F8 and null
ciphers.
Ronald S. Bultje [Mon, 14 Jan 2013 05:46:44 +0000 (21:46 -0800)]
h264: don't clobber mmco opcode tables for non-first slice headers.
Clobbering these tables will temporarily clobber the template used
as a basis for other threads to start decoding from. If the other
decoding thread updates from the template right at that moment,
subsequent threads will get invalid (or, usually, none at all) mmco
tables. This leads to invalid reference lists and subsequent decode
failures.
Therefore, instead, decode the mmco tables only for the first slice in
a field or frame. For other slices, decode the bits and ensure they
are identical to the mmco tables in the first slice, but don't ever
clobber the context state. This prevents other threads from using a
clobbered/invalid template as starting point for decoding, and thus
fixes decoding in these cases.
This fixes occasional (~1%) failures of h264-conformance-mr1_bt_a with
frame-multithreading enabled.
Martin Storsjö [Mon, 14 Jan 2013 09:34:19 +0000 (11:34 +0200)]
rtpdec: Handle more received packets than expected when sending RR
Without this, we'd signal a huge loss rate (due to unsigned
wraparound) if we had received one packet more than expected (that
is, one seq number sent twice). The code has a check for lost_interval
<= 0, but that doesn't do what was intended as long as the variable is
unsigned.
Anton Khirnov [Wed, 31 Oct 2012 05:42:08 +0000 (06:42 +0100)]
avpacket: free side data in av_free_packet().
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.
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.
projects / ffmpeg / log