Aaron Colwell [Mon, 19 Mar 2012 03:03:00 +0000 (20:03 -0700)]
vp8: avoid race condition on segment map.
This change avoids accessing the segment map of the previous frame if
segmentation is not enabled for the current frame. The caller of
decode_mb_mode() only calls ff_thread_await_progress() on the reference
segmentation index array if segmentation is enabled, so Chromium's TSAN
will report a race when accessing this data while segmentation is not
enabled.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Martin Storsjö [Mon, 19 Mar 2012 11:56:25 +0000 (13:56 +0200)]
rtpenc: Use AVFormatContext.packet_size instead of a private option
The private option has not been part of any release yet (and
it is only of use in quite rare cases), so just remove it instead
of keeping it with deprecation warnings.
Martin Storsjö [Mon, 19 Mar 2012 12:24:04 +0000 (14:24 +0200)]
libavformat: Use AVFormatContext.probesize in init_input
This was forgotten in the transition from av_open_input_file to
avformat_open_input, see 603b8bc2a1.
This doesn't change anything for the default case where the
option isn't set, since PROBE_BUF_MAX is 1048576 (which was
used as max probe size earlier) while the default value for
the probesize option is 5000000, which for the probe function
is clipped to PROBE_BUF_MAX anyway.
Justin Ruggles [Sat, 17 Mar 2012 15:42:49 +0000 (11:42 -0400)]
wmaenc: remove bit-exact hack
It may have improved cross-platform stability, but wasn't the only place in
the encoder with bitexact issues. It is no longer needed because we have FATE
tests for float encoders using fuzzy comparison.
Antonio Ospite [Fri, 16 Mar 2012 21:23:34 +0000 (22:23 +0100)]
x11grab: fix a memory leak exposed by valgrind
When using "-f x11grab -i :0.0" valgrind reports a definitely lost
memory block with this message:
==31544== 5 bytes in 1 blocks are definitely lost in loss record 1 of 2
==31544== at 0x4026E68: memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31544== by 0x4026F17: posix_memalign (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31544== by 0x60D399A: av_malloc (in /usr/lib/x86_64-linux-gnu/libavutil.so.51.22.1)
==31544== by 0x60D3A70: av_strdup (in /usr/lib/x86_64-linux-gnu/libavutil.so.51.22.1)
==31544== by 0x4A2BE58: ??? (in /usr/lib/x86_64-linux-gnu/libavdevice.so.53.2.0)
==31544== by 0x506D29E: avformat_open_input (in /usr/lib/x86_64-linux-gnu/libavformat.so.53.21.0)
==31544== by 0x400A80: main (in /home/ao2/WIP/am7xxx-play/tests/a.out)
The 5 bytes lost are the ones from param = av_strdup(":0.0"), so let's
free param in the exit path.
Also check the av_strdup() return value.
Note: calling av_free(param) even when av_strdup() fails and param is
NULL is OK and keeps the code simpler without adding another label to
skip av_free().
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Uoti Urpala [Fri, 16 Mar 2012 03:42:26 +0000 (05:42 +0200)]
threads: fix old frames returned after avcodec_flush_buffers()
Calling avcodec_flush_buffers() and then avcodec_decode_video2() with
a 0-sized packet (to get remaining buffered frames) could incorrectly
return an old frame from before the avcodec_flush_buffers() call. Add
a loop in ff_thread_flush() to zero the got_frame field of each thread
to ensure the old frames will not be returned.
Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>
Janne Grunau [Fri, 16 Mar 2012 13:08:17 +0000 (14:08 +0100)]
MPV: always mark dummy frames as reference
If the dummy frame are not created from a reference frame they could
be deleted untimely resulting in multithreaded decoder waiting on
the current frame to finish.
Noticed by Ronald S. Bultje in the RV34 decoder with a broken file.
Ronald S. Bultje [Fri, 16 Mar 2012 22:24:08 +0000 (15:24 -0700)]
h264: fix deadlocks on incomplete reference frame decoding.
If decoding a second complementary field, and the first was
decoded in our thread, mark decoding of that field as complete.
If decoding fails, mark the decoded field/frame as complete.
Do not allow switching between field modes or field/frame mode
between slices within the same field/frame. Ensure that two
subsequent fields cover top/bottom (rather than top/frame,
bottom/frame or such nonsense situations).
Fixes various deadlocks when decoding samples with errors in
reference frames.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org
Justin Ruggles [Sat, 10 Mar 2012 21:37:41 +0000 (16:37 -0500)]
FATE: add capability for audio encode/decode tests with fuzzy psnr comparison
This allows for testing floating-point audio encoders across different
platforms where exact comparisons are unreliable due to float rounding
differences.
Ronald S. Bultje [Tue, 13 Mar 2012 23:26:44 +0000 (16:26 -0700)]
h264: stricter reference limit enforcement.
Progressive images can have only 16 references, error out if there are
more, since the data is almost certainly corrupt, and the invalid value
will lead to random crashes or invalid writes later on.
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind CC: libav-stable@libav.org