The actual hwaccel code will need to access an internal context instead
of avctx->hwaccel_context, so add a new DXVA_CONTEXT() macro, that will
dispatch between the "old" external and the new internal context.

Also, the new API requires a new D3D11 pixfmt, so all places which check
for the pixfmt need to be adjusted. Introduce a ff_dxva2_is_d3d11()
function, which does the check.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

So a hwaccel can access avctx->hwaccel in init for whatever reason. This
is for the new d3d hwaccel API. We could create separate entrypoints for
each of the 3 hwaccel types (dxva2, d3d11va, new d3d11va), but this
seems nicer.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

To be used with the new d3d11 hwaccel decode API.

With the new hwaccel API, we don't want surfaces to depend on the
decoder (other than the required dimension and format). The old D3D11VA
pixfmt uses ID3D11VideoDecoderOutputView pointers, which include the
decoder configuration, and thus is incompatible with the new hwaccel
API. This patch introduces AV_PIX_FMT_D3D11, which uses ID3D11Texture2D
and an index. It's simpler and compatible with the new hwaccel API.

The introduced hwcontext supports only the new pixfmt.

Frame upload code untested.

Significantly based on work by Steve Lhomme <robux4@gmail.com>, but with
heavy changes/rewrites.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Both libraries provide similar functionality and cannot be used together.
When both are enabled one is used and the other ignored arbitrarily. Error
out instead and have the user choose which library to use.

This allows for more graceful fallback from NASM to Yasm if the available
NASM version is too old.

avtools/cmdutils.c:1234:28: warning: unused variable ‘pix_fmt’ [-Wunused-variable]

The .version files are only relevant during an actual build.

This makes ubsan happy and also considerably increases performance on
big endian systems.

Tested on an IBM POWER7 3.55 GHz

Before:

2.24user 0.14system 0:02.39elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
2.26user 0.11system 0:02.38elapsed 99%CPU (0avgtext+0avgdata 2688maxresident)k
2.23user 0.15system 0:02.38elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
2.25user 0.12system 0:02.38elapsed 100%CPU (0avgtext+0avgdata 2624maxresident)k
2.20user 0.15system 0:02.36elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k

After:

1.86user 0.13system 0:02.00elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
1.89user 0.11system 0:02.01elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
1.85user 0.14system 0:02.00elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
1.84user 0.15system 0:01.99elapsed 99%CPU (0avgtext+0avgdata 2624maxresident)k
1.89user 0.13system 0:02.02elapsed 99%CPU (0avgtext+0avgdata 2688maxresident)k
Tested-by: Nicolas George <george@nsup.org>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Sean McGovern <gseanmcg@gmail.com>

TLS is currently implemented over either OpenSSL or GnuTLS, with more
backends likely to appear in the future. Currently, those backend libraries
are part of the protocol names used during e.g. the configure stage of a
build. Hide those details behind a generically-named declaration for the
TLS protocol to avoid leaking those details into the configuration stage.

Return sensible error values and forward error codes.

Fixes out of array access
Fixes: ce19e41f0ef1e52a23edc488faecdb58/asan_heap-oob_2504e97_4202_ffa0df1baed14022b9bfd4f8ac23d0cb.smk

Bug-Id: CVE-2015-8365
CC: libav-stable@libav.org

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
(cherry picked from commit 4a9af07a)
Signed-off-by: Diego Biurrun <diego@biurrun.de>

If we for some unexplicable reason didn't pick up getaddrinfo
at configure, the default, IPv4-only, fallback should be good enough.

This effectively reverts 6023d84a.
Signed-off-by: Martin Storsjö <martin@martin.st>

This makes the getaddrinfo functions visible, which aren't normally
by default on legacy mingw.

We already force __MSVCRT_VERSION__ to an XP version.
Signed-off-by: Martin Storsjö <martin@martin.st>

Parse the playlist to recover the start sequence and previously
generated segments and continue muxing from there.

Mainly useful for near-seamless recovery in live scenarios.

This was actually broken when committed in 46e3936f; the
test never succeeded, and thus, _aligned_malloc wasn't actually
used on legacy mingw.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Clang support for Altivec/VSX uses a different approach.

Add dxva2_pool_release_dummy() and use it in call to
av_buffer_create() in dxva2_pool_alloc().

Prior to this change, av_buffer_create() was called with NULL for the
third argument, which indicates that av_buffer_default_free() should
be used to free the buffer's data.  Eventually, it gets to
buffer_pool_free() and calls buf->free() on a surface object (which is
av_buffer_default_free()).

This can result in a crash when the debug version of the C-runtime is
used on Windows.  While it doesn't appear to result in a crash when
the release version of the C-runtime is used on Windows, it likely
results in memory corruption, since av_free() is being called on
memory that was allocated using
IDirectXVideoAccelerationService::CreateSurface().
Signed-off-by: Aaron Levinson <alevinsn@aracnet.com>
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Reviewed-by: Mark Thompson <sw@jkqxz.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Currently it does not work at all.

Bug-Id: 1058

HEVCSEIPictureHash should store only the information extracted from the
bitstream and exported to the higher layer (the decoder or the parser).
The MD5 context is allocated, used and freed by this higher layer, so it
makes more sense for it to also be stored there.

This mimics the behavior of the now unused h264/hevc parser's split()
function and fixes decoding some files when extract_extradata bsf is
enabled.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Avoids unnecessary allocs+copies and makes the code slightly simpler.

While not yet used, these NAL units do already have some defined
semantics and are referred to elsewhere.

This avoids confusion with equivalent H.265 SEI values when both are
being used at the same time.

Same as f64d1100, for stream copy
rather than encode.

Signed-off-by: Martin Storsjö <martin@martin.st>

In these cases, the CTTS flag is set, but no edit list is necessary.
Signed-off-by: Martin Storsjö <martin@martin.st>

This reduces the need for an edit list; streams that start with
e.g. dts=-1, pts=0 can be encoded as dts=0, pts=0 (which is valid
in mov/mp4) by shifting the dts values of all packets forward.
This avoids the need for edit lists for such streams (while they
still are needed for audio streams with encoder delay).

This eases conformance with the DASH-IF interoperability guidelines.
Signed-off-by: Martin Storsjö <martin@martin.st>

Loads from this strictly doesn't require alignment, but specify it
just for consistency with the arm version.
Signed-off-by: Martin Storsjö <martin@martin.st>

clang now (in the upcoming 5.0 version) is capable of building our
arm assembly without relying on gas-preprocessor, although clang/LLVM
doesn't support .dn register aliases.

The VC1 MC assembly was only built and used if the chosen assembler
supported the .dn directives though. This was supported as long as
gas-preprocessor was used.

This means that VC1 decoding got a speed regression on clang 5.0,
unless the user manually chose using gas-preprocessor again.

By avoiding using the .dn register aliases, we can build the VC1 MC
assembly with the latest clang version.

Support for the .dn/.qn directives in clang/LLVM isn't actively planned,
see https://bugs.llvm.org/show_bug.cgi?id=18199.

This partially reverts 896a5bff.
Signed-off-by: Martin Storsjö <martin@martin.st>

This is more correct.
Signed-off-by: Martin Storsjö <martin@martin.st>

Bug-Id: 1036
CC: libav-stable@libav.org

It doesn't depend on hevcdec anymore.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Based on the H264 SEI implementation.

This will be mainly useful once support for SEI messages that can be
used by the hevc parser are implemented, like Picture Timing.
Signed-off-by: James Almer <jamrial@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

When targeting windows, the .arch directive isn't available.

So far, when building for windows, we've always used gas-preprocessor,
both when using msvc's armasm and when using clang. Lately, clang/llvm
has implemented the last missing piece (altmacro support) for building
our assembly without gas-preprocessor. This means that we now build
for arm/windows with clang without any extra compatibility layer.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>