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.

Bug-Id: 449

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.

This unclutters the top-level directory and groups related files together.

By default it is -1.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This fixes build failures for iOS, broken since cad42fad.
Signed-off-by: Martin Storsjö <martin@martin.st>

Calling ff_h264_field_end() when the per-field state is not properly
initialized leads to all kinds of undefined behaviour.

CC: libav-stable@libav.org
Bug-Id: 977 978 992

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.

CC: libav-stable@libav.org
Bug-ID: 999

CC: libav-stable@libav.org
Bug-Id: 981
Found-By: Agostino Sarubbo

CC: libav-stable@libav.org
Bug-Id: 981
Found-By: Agostino Sarubbo

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.

CC: libav-stable@libav.org
Bug-Id: 1000
Found-By: Kamil Frankowicz

Partially based on a patch by Timo Rothenpieler <timo@rothenpieler.org>.
Additional scaling list handling fix by Jun Zhao <mypopydev@gmail.com>.

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).

It should only be set after the decoder state has been fully initialized
for using that SPS.
Fixes possible invalid reads on get_format() failure.

CC: libav-stable@libav.org

This mapping has nothing to do with decoder implementations, so using
decoder names is wrong.

This allows enabling or disabling the library-related variables from
within the function instead of doing it manually outside of it.

Check for and link against user32 instead, which also fixes
the missing dependency of dxva2 on user32 with MSVC.

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>

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.
Signed-off-by: Martin Storsjö <martin@martin.st>

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.

There is no point in keeping the two separate.

Also move #includes into canonical order where appropriate.

This is more consistent and fixes compilation with clang.

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.