On Thu, 8 Jun 2017, wm4 wrote:
Module: libav
Branch: master
Commit: fff90422d181744cd75dbf011687ee7095f02875
Author: wm4 <nfx...@googlemail.com>
Committer: Diego Biurrun <di...@biurrun.de>
Date: Tue Jun 6 18:51:07 2017 +0200
lavu: add new D3D11 pixfmt and hwcontext
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 <rob...@gmail.com>, but with
heavy changes/rewrites.
Signed-off-by: Diego Biurrun <di...@biurrun.de>
---
doc/APIchanges | 3 +
libavutil/Makefile | 3 +
libavutil/hwcontext.c | 4 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_d3d11va.c | 490 +++++++++++++++++++++++++++++++++++++++++
libavutil/hwcontext_d3d11va.h | 160 ++++++++++++++
libavutil/hwcontext_internal.h | 1 +
libavutil/pixdesc.c | 4 +
libavutil/pixfmt.h | 14 +-
libavutil/version.h | 4 +-
10 files changed, 681 insertions(+), 3 deletions(-)
+static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device,
+ AVDictionary *opts, int flags)
+{
+ AVD3D11VADeviceContext *device_hwctx = ctx->hwctx;
+ HANDLE d3dlib;
+
+ HRESULT hr;
+ PFN_D3D11_CREATE_DEVICE createD3D;
+ IDXGIAdapter *pAdapter = NULL;
+ ID3D10Multithread *pMultithread;
+ UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
+
+ if (device) {
+ PFN_CREATE_DXGI_FACTORY mCreateDXGIFactory;
+ HMODULE dxgilib = LoadLibrary("dxgi.dll");
+ if (!dxgilib)
+ return AVERROR_UNKNOWN;
Sorry for being late to the party, but... This broke compilation of a few
of my fate instances: https://fate.libav.org/arm-msvc-15/20170609072420
(I know this was passed via oracle, but I don't have all configurations
set up there.)
LoadLibrary isn't available when targeting the UWP API subsets. This was
recently discussed on ffmpeg-devel also:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212076.html
In this case, falling back to LoadPackagedLibrary probably doesn't make
much sense (since it expclitly only allows loading libraries that were
packaged with the app, not system libs).
I guess one should just link directly to the functions in this scenario.
Since LoadLibrary is unavailable, people packaging UWP apps either need to
bump their minimum required version (although I guess D3D11 is available
in the baseline version for such apps?) or disable the feature.
I'll post a RFC patch that made the build pass for me at least.
// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
