This improves commit 59c70227.

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>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This could happen when there was a frame number gap and frame threading was used.
Debugging-by: Ronald S. Bultje <rsbultje@gmail.com>
Debugging-by: Justin Ruggles <justin.ruggles@gmail.com>
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

CC:libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This makes sure ff_get_format() does not get called unnecessarily from
update_thread_context().

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.

Significantly increases the efficiency of frame threading, since
individual frames in a superframe can now be decoded in parallel.

Partially based on code by Ronald S. Bultje <rsbultje@gmail.com>.

Drop the internal manual conversion from the MP4 format to Annex B.

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.

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.

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.

This partially reverts commit ac648bb8.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

The feature has outlived is usefulness and complicates the code.

Same issue as 17a0f948.

This is required to make certain math defines visible on modern Cygwin.

This makes naming more consistent and simplifies extralibs-related changes.

This is more in line with the other related variable names.

These components should depend on the availability of the respective
libraries, not just on the availability of the respective headers.

These are taken care of more correctly by the library checks.

That header should only be included in the special bits that use X11 code.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Make avio_size() work with any write AVIOContext.

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Also preserve the return value from ff_get_buffer().
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

They are not valid and can cause problems/crashes for API users.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Also use av_mallocz_array().

Bug-Id: CID 1396839
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Bug-Id: CID 1396851
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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.
Signed-off-by: Wan-Teh Chang <wtc@google.com>

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.
Signed-off-by: Wan-Teh Chang <wtc@google.com>