Henrik Gramner [Sun, 25 Dec 2016 19:24:59 +0000 (20:24 +0100)]
x86inc: Avoid using eax/rax for storing the stack pointer
When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.
If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
Martin Storsjö [Fri, 30 Dec 2016 19:45:51 +0000 (21:45 +0200)]
fate: Skip the checkasm test if CONFIG_STATIC is disabled
When building DLLs with MSVC, CONFIG_STATIC is disabled (see d66c52c2b3694 for a more verbose explanation) since the built
object files can't be linked statically (which checkasm does).
Jun Zhao [Fri, 11 Nov 2016 06:53:49 +0000 (14:53 +0800)]
vaapi_h264: Fix POC on IDR frames
In H.264 section 8.2.1, we have that "The bitstream shall not contain
data that result in Min(TopFieldOrderCnt, BottomFieldOrderCnt) not
equal to 0 for a coded IDR frame". This fixes the encoder to always
conform to this - previously the POC values formed an unbroken
sequence, not resetting to zero on IDR frames.
Diego Biurrun [Tue, 20 Dec 2016 13:27:19 +0000 (14:27 +0100)]
build: Generate pkg-config files from Make and not from configure
This moves work from the configure to the Make stage where it can
be parallelized and ensures that pkgconfig files are updated when
library versions change.
Diego Biurrun [Sat, 17 Dec 2016 19:01:07 +0000 (20:01 +0100)]
build: Store library version numbers in .version files
This moves work from the configure to the Make stage where it can
be parallelized and ensures that shared libraries are built with
the right version number in the filename.
Anton Khirnov [Sat, 17 Dec 2016 16:04:55 +0000 (17:04 +0100)]
mpeg12dec: move setting first_field to mpeg_field_start()
For field picture, the first_field is set based on its previous value.
Before this commit, first_field is set when reading the picture
coding extension. However, in corrupted files there may be multiple
picture coding extension headers, so the final value of first_field that
is actually used during decoding can be wrong. That can lead to various
undefined behaviour, like predicting from a non-existing field.
Fix this problem, by setting first_field in mpeg_field_start(), which
should be called exactly once per field.
Anton Khirnov [Sat, 17 Dec 2016 13:17:20 +0000 (14:17 +0100)]
mov: fix a possible invalid read in mov_read_mac_string()
When the input string is too large, so the second condition in if ()
fails, the code will erroneously execute the else branch, indexing the
mac_to_unicode table with a negative index.
Anton Khirnov [Thu, 24 Nov 2016 14:14:22 +0000 (15:14 +0100)]
pthread_frame: do not run hwaccel decoding asynchronously unless it's safe
Certain hardware decoding APIs are not guaranteed to be thread-safe, so
having the user access decoded hardware surfaces while the decoder is
running in another thread can cause failures (this is mainly known to
happen with DXVA2).
For such hwaccels, only allow the decoding thread to run while the user
is inside a lavc decode call (avcodec_send_packet/receive_frame).
Steve Lhomme [Thu, 15 Dec 2016 17:00:56 +0000 (18:00 +0100)]
configure: fix linking with MSVC when using --disable-optimizations
Without any optimization flags, MSVC does no dead code elimination (DCE) at
all, even for the most trivial cases. DCE is a prerequisite for building libav
correctly, otherwise there are undefined references to functions for other
architectures and disabled components.
-O1 is the minimal optimization flag for MSVC that does include DCE.
When receiving fragmented packets, the first packet declares the size,
and the later ones normally are small follow-on packets that don't repeat
the size and the other header fields. But technically, the later fragments
also can have a full header, declaring a different size than the previous
packet.
If the follow-on packet declares a larger size than the initial one, we
could end up writing outside of the allocation.
This fixes out of bounds writes.
Found-by: Paul Cher <paulcher@icloud.com> Reviewed-by: Paul Cher <paulcher@icloud.com> CC: libav-stable@libav.org Signed-off-by: Martin Storsjö <martin@martin.st>
Martin Storsjö [Thu, 15 Dec 2016 07:45:49 +0000 (09:45 +0200)]
libavformat: Fix a faulty api deprecation guard in prepare_input_packet
This seems to have been added by mistake in 11de006b, by not
noticing the negation for the existing condition. This block does
not contain any code that accesses the codec field in AVStream.
This function is meant to serve as a complement to compute_pkt_fields2,
which is guarded by FF_API_COMPUTE_PKT_FIELDS2 && FF_API_LAVF_AVCTX.
Janne Grunau [Thu, 8 Dec 2016 19:40:34 +0000 (20:40 +0100)]
arm64: replace 'bic' with immediate with 'and' with inverted immediate
The former is not an official pseudo instruction although gas and llvm's
internal assembler support it. Fixes a build error with xcode 6.2
reported by Memphiz on github.
In ff_thread_report_progress(), the fast code path can load
progress[field] with the relaxed memory order, and the slow code path
can store progress[field] with the release memory order. These changes
are mainly intended to avoid confusion when one inspects the source code.
They are unlikely to have measurable performance improvement.
ff_thread_report_progress() and ff_thread_await_progress() form a pair.
ff_thread_await_progress() reads progress[field] with the acquire memory
order (in the fast code path). Therefore, one expects to see
ff_thread_report_progress() write progress[field] with the matching
release memory order.
In the fast code path in ff_thread_report_progress(), the atomic load of
progress[field] doesn't need the acquire memory order because the
calling thread is trying to make the data it just decoded visible to the
other threads, rather than trying to read the data decoded by other
threads.
In ff_thread_get_buffer(), initialize progress[0] and progress[1] using
atomic_init().
Signed-off-by: Wan-Teh Chang <wtc@google.com> Signed-off-by: Anton Khirnov <anton@khirnov.net>
Anton Khirnov [Thu, 24 Nov 2016 22:05:20 +0000 (23:05 +0100)]
binkaudio: switch to the new send/receive API
It is more natural for this codec and allows to avoid awkward constructs
like "consuming 0 bytes from input". Also, keep a reference to the input
packet to avoid unnecessary copying.
Anton Khirnov [Wed, 26 Oct 2016 11:59:15 +0000 (13:59 +0200)]
decode: restructure the core decoding code
Currently, the new decoding API is pretty much just a wrapper around the
old deprecated one. This is problematic, since it interferes with making
full use of the flexibility added by the new API. The old API should
also be removed at some future point.
Reorganize the code so that the new send_packet/receive_frame functions
call the actual decoding directly and change the old deprecated
avcodec_decode_* functions into wrappers around the new API.
The new internal API for decoders is now changing as well. Before this
commit, it mirrors the public API, so the decoders need to implement
send_packet() and receive_frame() callbacks. This turns out to require
awkward constructs in both the decoders and the generic code. After this
commit, the decoders only implement the receive_frame() callback and
call a new internal function, ff_decode_get_packet() to obtain input
data, in the same manner to how the bitstream filters now work.
avcodec will now always make a reference to the input packet, which means
that non-refcounted input packets will be copied. Keeping the previous
behaviour, where this copy could sometimes be avoided, would make the
code significantly more complex and fragile for only dubious gains,
since packets are typically small and everyone who cares about
performance should use refcounted packets anyway.
Anton Khirnov [Wed, 26 Oct 2016 11:41:12 +0000 (13:41 +0200)]
decode: be more explicit about storing the last packet properties
The current code stores a pointer to the packet passed to the decoder,
which is then used during get_buffer() for timestamps and side data
passthrough. However, since this is a pointer to user data which we do
not own, storing it is potentially dangerous. It is also ill defined for
the new decoding API with split input/output.
Fix this problem by making an explicit internally owned copy of the
packet properties.
Anton Khirnov [Tue, 24 May 2016 13:09:29 +0000 (15:09 +0200)]
lavc: add a null bitstream filter
It is useful for testing/debugging and will also be used as the default
filter in the following commit adding pre-decode filtering to avoid
having a separate non-filtered codepath.
Wan-Teh Chang [Sat, 3 Dec 2016 00:56:16 +0000 (16:56 -0800)]
compat/atomics: add typecasts in atomic_compare_exchange_strong()
The Solaris and Windows emulations of atomic_compare_exchange_strong()
need typecasts to avoid compiler warnings, because the functions they
call expect a void* pointer but an intptr_t integer is passed.
Note that the emulations of atomic_compare_exchange_strong() (except
the gcc version) only work for atomic_intptr_t because of the type of
the second argument (|expected|). See
http://en.cppreference.com/w/c/atomic:
_Bool atomic_compare_exchange_strong( volatile A* obj,
C* expected, C desired );
The types of the first argument and second argument are different
(|A| and |C|, respectively). |C| is the non-atomic type corresponding
to |A|. In the emulations of atomic_compare_exchange_strong(), |C| is
intptr_t. This implies |A| can only be sig_intptr_t.
Wan-Teh Chang [Thu, 8 Dec 2016 00:16:02 +0000 (16:16 -0800)]
avutil: fix data race in av_get_cpu_flags()
Make the one-time initialization in av_get_cpu_flags() thread-safe. The
static variables |flags|, |cpuflags_mask|, and |checked| in
libavutil/cpu.c are read and written using normal load and store
operations. These are considered as data races. The fix is to use atomic
load and store operations.
Remove the |checked| variable because the invalid value of -1 for
|flags| can be used to indicate the same condition. Rename |flags| to
|cpu_flags| and move it to file scope.
The fix can be verified by running the libavutil/tests/cpu_init.c test
program under ThreadSanitizer:
./configure --toolchain=clang-tsan
make libavutil/tests/cpu_init
libavutil/tests/cpu_init
There should be no warnings from ThreadSanitizer.
Co-author: Dmitry Vyukov of Google, who suggested the data race fix.
projects / ffmpeg / log