Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic function for this seems helpful.
In order to handle the complex cases in a generic way without destroying
performance, this code attempts to compute a black pixel, and then uses
that value to clear the image data quickly by using a function like
memset.
Common cases like yuv410p10 or rgba can't be handled with a simple
memset, so there is some code to fill memory with 2/4/8 byte patterns.
For the remaining cases, a generic slow fallback is used.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
If using the winstore compat library, a fallback LoadLibrary
function does exist, that only calls LoadPackagedLibrary though
(which doesn't work for dynamically loading d3d11 DLLs).
Therefore explicitly check the targeted API family instead.
Make this check a reusable HAVE_* component which other parts
of the libraries can check when necessary as well.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some devices (some phones, apparently) will support only this opaque
format. Of course this won't work with CLI, because copying data
directly is not supported.
Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does
not support this mode, even if it's the only supported mode. But since
opaque surfaces are generally less useful, that's probably ok.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Makes dealing with formats that can not be used for staging textures
easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging
texture is never needed, so this is a good thing.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
It appears in this case, frames_ininit is called twice (once by
av_hwframe_ctx_init(), and again by unreffing the frames ctx ref).
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
When targeting the UWP API subset, the LoadLibrary function is not
available (and the fallback, LoadPackagedLibrary, can't be used to
load system DLLs). In these cases, link directly to the functions
in the DLLs instead of trying to load them dynamically at runtime.
Signed-off-by: Martin Storsjö <martin@martin.st>
This also adds support to avconv (which is trivial due to the new
hwaccel API being generic enough).
The new decoder setup code in dxva2.c is significantly based on work by
Steve Lhomme <robux4@gmail.com>, but with heavy changes/rewrites.
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>
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>
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>
Use the flags argument of av_hwframe_ctx_create_derived() to pass the
mapping flags which will be used on allocation. Also, set the format
and hardware context on the allocated frame automatically - the user
should not be required to do this themselves.
Some frames contexts are not usable without additional format-specific
state in hwctx. This change adds new functions frames_derive_from and
frames_derive_to to initialise this state appropriately when deriving
a frames context which will require it to be set.
Inlining public functions hardcodes their implementation into the ABI,
so it should be avoided unless there is a very good reason for it. No
such reason exists in this case.
Previously, the former form always produced a manually aligned,
padded buffer, while the latter can use DECLARE_ALIGNED, if that
amount of stack alignment is supported.
libavutil/internal.h needs to include mem.h, since it uses
the DECLARE_ALIGNED macro.
Signed-off-by: Martin Storsjö <martin@martin.st>
These values are defined to be 32bit in the specification,
so it makes more sense to store them as fixed width.
Based on a patch by Micahel Niedermayer <michael@niedermayer.cc>.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This disables everything that was deprecated at least 18 months ago.
Readjust the minimum API version as needed, postponing any
API-incompatible changes until the next bump.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Hook up all attributes that don't have a MSVC specific version at the
moment.
See f637046d31 for details.
These don't seem to be critical for building with clang in MSVC mode
though, and thus haven't been hooked up until now.
These seem to build fine with as old clang as 3.3 at least.
(clang 3.3 disguises itself as gcc 4.2 normally, so all of these
have been used for clang before, except for av_cold.)
The clang version numbers themselves are useless for detecting what
attributes are available, since Apple's clang builds use a completely
different versioning (presenting itself as e.g. clang 8.0 instead
of 3.8).
Signed-off-by: Martin Storsjö <martin@martin.st>
This is a follow-up to f637046d31.
Without the noreturn attribute set, avconv_opt.c fails to build after
d2e6dd32a4 with the error "control may reach end of non-void function".
By making sure the noreturn attribute is set properly, this compiles
as intended.
Signed-off-by: Martin Storsjö <martin@martin.st>
Adds functions to convert to/from strings and a function to iterate
over all supported device types. Also adds a new invalid type
AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
Also do some small cosmetic changes: Drop pointless _MMX suffix from ABSD2
macro name, drop pointless check for MMX support, we always assume MMX is
available in our SIMD code, fix spelling.
The driver is somewhat bitrotten (not updated for years) but is still
usable for decoding with this change. To support it, this adds a new
driver quirk to indicate no support at all for surface attributes.
Based on a patch by wm4 <nfxjfg@googlemail.com>.
D3D9Ex uses different driver paths. This helps with "headless"
configurations when no user logs in. Plain D3D9 device creation will
fail if no user is logged in, while it works with D3D9Ex.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
This is an extended version of the AVFrame.opaque field, which can be
used to attach arbitrary user information to an AVFrame.
The usefulness of the opaque field is rather limited, because it can
store only up to 32 bits of information (or 64 bit on 64 bit systems).
It's not possible to set this field to a memory allocation, because
there is no way to deallocate it correctly.
The opaque_ref field circumvents this by letting the user set an
AVBuffer, which makes the user data refcounted.
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Vittorio Giovara
wm4
Martin Storsjö
Mark Thompson
Diego Biurrun
James Almer
Elviss Strazdins
Aaron Levinson
Anton Khirnov
Paul B Mahol
Ganesh Ajjanagadde