Martin Storsjö [Sat, 19 Jan 2013 23:59:08 +0000 (01:59 +0200)]
mpegts: Share the cleanup code between the demuxer and lavf-internal parser functions
The lavf-internal parser functions are used when receiving
mpegts over RTP. This fixes memory leaks in this setup.
The normal mpegts demuxer close function was updated in ec7d0d2e in
2004 to fix leaks, but the parsing function used for RTP wasn't
updated and has been leaking ever since.
libavutil/arm/asm.S sets '.arch' depending on HAVE_ARMV5TE so that
assembling armv5te code will always succeed even if the default -march
flag does not support it. HAVE_ARMV5TE_EXTERNAL tests assembling code
with the default arch.
Fixes the missing symbol ff_prefetch_arm with --cpu= not including
armv5te.
Anton Khirnov [Thu, 17 Jan 2013 11:25:31 +0000 (12:25 +0100)]
h264: avoid pointless copying of ref lists
ref_list is constructed from other fields per slice when needed, so do
not copy it for both frame and slice threading.
default_ref_list is constructed per frame and still needs to be copied
to per-slice contexts for slice threading, but a copy is not needed for
frame threading.
Justin Ruggles [Wed, 16 Jan 2013 19:15:57 +0000 (14:15 -0500)]
lavr: call mix_function_init() in ff_audio_mix_set_matrix()
This is needed if a custom matrix is set by the user after opening the
AVAudioResampleContext because the matrix channel count can change if
different mixing coefficients are used.
Martin Storsjö [Thu, 17 Jan 2013 14:03:36 +0000 (16:03 +0200)]
theora: Skip zero-sized headers
This fixes a regression since d9cf5f51 with theora over RTP
(possibly with other variants of theora as well).
In theora over RTP, the second of the 3 headers turns out to be
0 bytes long, which prior to d9cf5f51 worked just fine. After d9cf5f51, reading from the bitstream reader fails (since the reader
wasn't initialized but returned an error if initialized with 0 bits).
CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
Ronald S. Bultje [Tue, 15 Jan 2013 16:38:54 +0000 (08:38 -0800)]
h264: add 3 pixels below for subpixel filter wait position
If the motion vector is at a subpixel position, we need 3 pixels below
the motion vector's wholepel position available, not 2, since the MC
filter is a sixtap filter for the hpel position, and then a bilin filter
for the qpel position.
This patch fixes highly irreproducible (0.1%) fate failures in frame 2
and 4 of h264-conformance-cama2_vtc_b (e.g. first P-frame, first field,
last line of MB x=40,y=2 and second field and last lines of MBs x=39-40,
y=3). These used pre-loopfilter instead of post-loopfilter data because
the await_progress() waited for one line too little in that field, and
the motion vector of these particular MBs happened to align exactly to a
position where that demonstrates the bug.
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.
projects / ffmpeg / log