Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
On 24/04/18 11:51, Alexander Kravchenko wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Mark Thompson
>> Sent: Sunday, April 22, 2018 6:49 PM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
>> implementation by AMF encoder
>>
>> On 19/04/18 03:18, Song, Ruiling wrote:
>>>> Note that OpenCL <-> D3D11 won't work on AMD for normal video
>>>> surfaces
>>>> (NV12) because there is no support for multiple-plane textures, so
>>>> it's only going to work with DXVA2 currently. Intel has an extension
>>>> ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack
>>>> overloading the subresource index and therefore it is usable on Intel
>>>> GPUs, but other vendors don't have that.
>>>
>>> For OpenCL NV12 support, I think we can use two separate images as
>>> arguments, one image for Y plane, and another image for UV plane.
>>> I think AMD OpenCL should support (CL_RG + CL_UNORM_INT8), right?
>>> So, we can get same behavior across different OpenCL vendors.
>>
>> This is exactly what it does already, in a standard way with both DXVA2 and
>> VAAPI - NV12 as R/UNORM_INT8 + RG/UNORM_INT8 is
>> indeed usable for AMD on Windows with DXVA2 interop and via direct upload.
>>
>> The problematic case is D3D11, because the standard cl_khr_d3d11_sharing
>> extension does not support multiple-plane formats. I
>> would prefer that AMD has an OpenCL-only extension to do it like Intel does,
>> but an alternative route using AMF to do the mapping
>> isn't horrible (though it would be quite confusing if it isn't transparent
>> to the user).
>
> The AMD OpenCL only extension is requested to be published. Hopefully it is
> coming soon.
Ah, good! Will it be the same as the Intel one? It would be nice if it were
defined for any multiplanar format rather than just NV12 (at the moment getting
P010 or anything else is only possible in the implementations which share via
DRM, currently Beignet and Mali).
> Now it is possible to convert DX11-NV12 surface to OpenCL-NV12 using AMF
> (AMFSurface->Convert(AMF_MEMORY_OPENCL)).
> The private helper function can be implemented as temporary workaround. It
> can be deprecated when opencl-only extension is published by AMD
If the extension is arriving any time soon then I think it would be better to
wait so that we can just use hwmap like all other cases do. A via-AMF route is
going to be somewhat more inconvenient to combine the required components, and
also deprecating public API soon after it is added is not very nice.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
> Thompson
> Sent: Sunday, April 22, 2018 6:49 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
> implementation by AMF encoder
>
> On 19/04/18 03:18, Song, Ruiling wrote:
> >> Note that OpenCL <-> D3D11 won't work on AMD for normal video
> >> surfaces
> >> (NV12) because there is no support for multiple-plane textures, so
> >> it's only going to work with DXVA2 currently. Intel has an extension
> >> ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack
> >> overloading the subresource index and therefore it is usable on Intel
> >> GPUs, but other vendors don't have that.
> >
> > For OpenCL NV12 support, I think we can use two separate images as
> > arguments, one image for Y plane, and another image for UV plane.
> > I think AMD OpenCL should support (CL_RG + CL_UNORM_INT8), right?
> > So, we can get same behavior across different OpenCL vendors.
>
> This is exactly what it does already, in a standard way with both DXVA2 and
> VAAPI - NV12 as R/UNORM_INT8 + RG/UNORM_INT8 is
> indeed usable for AMD on Windows with DXVA2 interop and via direct upload.
>
> The problematic case is D3D11, because the standard cl_khr_d3d11_sharing
> extension does not support multiple-plane formats. I
> would prefer that AMD has an OpenCL-only extension to do it like Intel does,
> but an alternative route using AMF to do the mapping
> isn't horrible (though it would be quite confusing if it isn't transparent to
> the user).
The AMD OpenCL only extension is requested to be published. Hopefully it is
coming soon.
Now it is possible to convert DX11-NV12 surface to OpenCL-NV12 using AMF
(AMFSurface->Convert(AMF_MEMORY_OPENCL)).
The private helper function can be implemented as temporary workaround. It can
be deprecated when opencl-only extension is published by AMD
The helper function implementation requires hwcontext_amf which is going to be
implemented soon (to be shared in amfenc and vf_scale_amf)
Thanks,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
On 19/04/18 03:18, Song, Ruiling wrote:
>> Note that OpenCL <-> D3D11 won't work on AMD for normal video surfaces
>> (NV12) because there is no support for multiple-plane textures, so it's only
>> going
>> to work with DXVA2 currently. Intel has an extension
>> ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack overloading
>> the subresource index and therefore it is usable on Intel GPUs, but other
>> vendors
>> don't have that.
>
> For OpenCL NV12 support, I think we can use two separate images as arguments,
> one image for Y plane, and another image for UV plane.
> I think AMD OpenCL should support (CL_RG + CL_UNORM_INT8), right?
> So, we can get same behavior across different OpenCL vendors.
This is exactly what it does already, in a standard way with both DXVA2 and
VAAPI - NV12 as R/UNORM_INT8 + RG/UNORM_INT8 is indeed usable for AMD on
Windows with DXVA2 interop and via direct upload.
The problematic case is D3D11, because the standard cl_khr_d3d11_sharing
extension does not support multiple-plane formats. I would prefer that AMD has
an OpenCL-only extension to do it like Intel does, but an alternative route
using AMF to do the mapping isn't horrible (though it would be quite confusing
if it isn't transparent to the user).
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> Note that OpenCL <-> D3D11 won't work on AMD for normal video surfaces
> (NV12) because there is no support for multiple-plane textures, so it's only
> going
> to work with DXVA2 currently. Intel has an extension
> ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack overloading
> the subresource index and therefore it is usable on Intel GPUs, but other
> vendors
> don't have that.
For OpenCL NV12 support, I think we can use two separate images as arguments,
one image for Y plane, and another image for UV plane.
I think AMD OpenCL should support (CL_RG + CL_UNORM_INT8), right?
So, we can get same behavior across different OpenCL vendors.
Ruiling
>
> (There should probably be a wiki page on all of this. I've never got around
> to
> writing it.)
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> -Original Message- > From: Alexander Kravchenko [mailto:akravchenko...@gmail.com] > Sent: Sunday, April 15, 2018 12:02 AM > To: 'FFmpeg development discussions and patches' > Subject: RE: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support > implementation by AMF encoder > > > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Mark Thompson > > Sent: Saturday, April 14, 2018 7:15 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures > > support implementation by AMF encoder > > > > > > I've sent a new set containing this patch as 3 and 4 (I split out the > > format check part, since that doesn't have anything to do with DXVA2), > > which hopefully makes the initialisation and surface mapping > setup cleaner. Would you like to look at that and comment? > > Quite a bit of stuff got moved around in the merge. > > > > > Hi Mark, > I briefly read the patches, they look good But I tried to apply them locally > The first one failed > 1) I cloned ffmpeg > 2) pasted patch text to file p1.patch > 3) git apply p1.patch > > error: patch failed: libavcodec/amfenc.c:152 > error: libavcodec/amfenc.c: patch does not apply > > it look like patch expexts "amf_load_library(AVCodecContext *avctx)" at line > 152 @@ -152,10 +152,30 @@ static int > amf_load_library(AVCodecContext *avctx) > > In github > https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/amfenc.c > it is on line 155 > > did I miss something? > > Thanks, > Alexander > I managed to apply patch, patch was broken by Far Manager Editor. Pasting patch text to nano solved the applying problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark > Thompson > Sent: Saturday, April 14, 2018 7:15 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support > implementation by AMF encoder > > > I've sent a new set containing this patch as 3 and 4 (I split out the format > check part, since that doesn't have anything to do with > DXVA2), which hopefully makes the initialisation and surface mapping setup > cleaner. Would you like to look at that and comment? > Quite a bit of stuff got moved around in the merge. > Hi Mark, I briefly read the patches, they look good But I tried to apply them locally The first one failed 1) I cloned ffmpeg 2) pasted patch text to file p1.patch 3) git apply p1.patch error: patch failed: libavcodec/amfenc.c:152 error: libavcodec/amfenc.c: patch does not apply it look like patch expexts "amf_load_library(AVCodecContext *avctx)" at line 152 @@ -152,10 +152,30 @@ static int amf_load_library(AVCodecContext *avctx) In github https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/amfenc.c it is on line 155 did I miss something? Thanks, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
On 13/04/18 10:21, Alexander Kravchenko wrote:
>
> This patch contains DXVA2 textures support implementation by AMF encoder (in
> addition of D3D11 textures)
>
> Samples of usage:
> DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
> ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i
> input.mp4 -an -c:v h264_amf out.mkv
>
> D3D11va decoder -> d3d11 texture -> AMF Encoder:
> ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i
> input.mp4 -an -c:v h264_amf out.mkv
>
> ---
> Sending updated patch (Fixes according Mark's review):
>>> ---
>>^
>> (When adding commentary which isn't part of the commit message to an email
>> please place it after this line so that it doesn't end up in the commit
>> message.)
> Done here, hopefully correctly
>
>>> { AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
>>> +{ AV_PIX_FMT_DXVA2_VLD, AMF_SURFACE_NV12 },
>>
>> As with D3D11, this isn't necessarily true. This was ignored before, but do
>> you have any plan for how P010 (and others?) will be handled here?
> removed HW types from format map, and added logic reading pixel format from
> avctx->sw_pix_fmt in case if avctx->pix_fmt is HWACCEL type
>
>> +static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr,
>> IDirect3DDevice9 **device, void *avcl) {
>> ...
>> Might be cleaner using an error return rather than the null device?
> Fixed
>
>> Everything using D3D9 types needs to be inside CONFIG_DXVA2
> Fixed
>
>> Passing NULL here will make this case succeed in cases where it shouldn't, I
>> think?
> Agree, fixed
>
>> Tbh I don't think this fallback case should exist at all, it should just
>> fail.
>> Is there any use-case for having it? The user passed a DXVA2 frames context
>> on a
>> non-AMD device and expects it to work with that hardware input, this
>> fallback makes
>> it kindof work with at least two copies in a way which is likely to be very
>> slow.
>> Even if the user does want to do that, it would be better for them to do it
>> explicitly
>> to ensure that they aware of the problem. (We don't automatically do this
>> in any other case.)
> Agree, fixed
>
>> Spurious whitespace.
> Fixed in changed blocks/functions
I've sent a new set containing this patch as 3 and 4 (I split out the format
check part, since that doesn't have anything to do with DXVA2), which hopefully
makes the initialisation and surface mapping setup cleaner. Would you like to
look at that and comment? Quite a bit of stuff got moved around in the merge.
>> Tested on Windows 7, works well.
>> Unlike with D3D11 the OpenCL interop works properly as well,
>> so e.g. -vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1
>> 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' as encoder input
>> works too.
> Could you send the samples (or link if they are published, I will add to my
> tests and will check OpenCL interop with D3D11)
Use any OpenCL filter with mapping to/from DXVA2. For example:
./ffmpeg_g -y -hwaccel dxva2 -hwaccel_output_format dxva2_vld -i input.mkv -an
-vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1
0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' -c:v h264_amf
output.mkv
(Applies an edge-detect convolution on the luma plane.)
The source filter is also usable with a little trickiness to get the right
setup:
./ffmpeg_g -y -init_hw_device dxva2=d3d -init_hw_device opencl=cl@d3d
-filter_hw_device cl -filter_complex
'openclsrc=source=sierpinski.cl:kernel=sierpinski_carpet:size=1920x1080:format=nv12,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16'
-c:v h264_amf output.mkv
(Using the sierpinski carpet example from the documentation.)
Note that OpenCL <-> D3D11 won't work on AMD for normal video surfaces (NV12)
because there is no support for multiple-plane textures, so it's only going to
work with DXVA2 currently. Intel has an extension
("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack overloading the
subresource index and therefore it is usable on Intel GPUs, but other vendors
don't have that.
(There should probably be a wiki page on all of this. I've never got around to
writing it.)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
This patch contains DXVA2 textures support implementation by AMF encoder (in
addition of D3D11 textures)
Samples of usage:
DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i
input.mp4 -an -c:v h264_amf out.mkv
D3D11va decoder -> d3d11 texture -> AMF Encoder:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i
input.mp4 -an -c:v h264_amf out.mkv
---
Sending updated patch (Fixes according Mark's review):
> > ---
>^
> (When adding commentary which isn't part of the commit message to an email
> please place it after this line so that it doesn't end up in the commit
> message.)
Done here, hopefully correctly
> > { AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
> > +{ AV_PIX_FMT_DXVA2_VLD, AMF_SURFACE_NV12 },
>
> As with D3D11, this isn't necessarily true. This was ignored before, but do
> you have any plan for how P010 (and others?) will be handled here?
removed HW types from format map, and added logic reading pixel format from
avctx->sw_pix_fmt in case if avctx->pix_fmt is HWACCEL type
> +static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr,
> IDirect3DDevice9 **device, void *avcl) {
> ...
> Might be cleaner using an error return rather than the null device?
Fixed
> Everything using D3D9 types needs to be inside CONFIG_DXVA2
Fixed
> Passing NULL here will make this case succeed in cases where it shouldn't, I
> think?
Agree, fixed
> Tbh I don't think this fallback case should exist at all, it should just fail.
> Is there any use-case for having it? The user passed a DXVA2 frames context
> on a
> non-AMD device and expects it to work with that hardware input, this fallback
> makes
> it kindof work with at least two copies in a way which is likely to be very
> slow.
> Even if the user does want to do that, it would be better for them to do it
> explicitly
> to ensure that they aware of the problem. (We don't automatically do this in
> any other case.)
Agree, fixed
> Spurious whitespace.
Fixed in changed blocks/functions
> Tested on Windows 7, works well.
> Unlike with D3D11 the OpenCL interop works properly as well,
> so e.g. -vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1
> 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' as encoder input
> works too.
Could you send the samples (or link if they are published, I will add to my
tests and will check OpenCL interop with D3D11)
libavcodec/amfenc.c | 158 +---
1 file changed, 126 insertions(+), 32 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..7cdf17a972 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
#if CONFIG_D3D11VA
#include "libavutil/hwcontext_d3d11va.h"
#endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
#include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
AV_PIX_FMT_YUV420P,
#if CONFIG_D3D11VA
AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
#endif
AV_PIX_FMT_NONE
};
@@ -68,7 +74,6 @@ static const FormatMap format_map[] =
{ AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
-{ AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
};
@@ -152,6 +157,26 @@ static int amf_load_library(AVCodecContext *avctx)
return 0;
}
+#if CONFIG_DXVA2
+static HRESULT get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr,
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(hr = devmgr->lpVtbl->OpenDeviceHandle(devmgr,
&device_handle))) {
+if (SUCCEEDED(hr = devmgr->lpVtbl->LockDevice(devmgr, device_handle,
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9
device: %lx.\n", (unsigned long)hr);
+}
+return hr;
+}
+#endif
+
static int amf_init_context(AVCodecContext *avctx)
{
AmfContext *ctx = avctx->priv_data;
@@ -177,34 +202,61 @@ static int amf_init_context(AVCodecContext *avctx)
res = ctx->factory->pVtbl->CreateContext(ctx->factory, &ctx->context);
AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext()
failed with error %d\n", res);
// try to reuse existing DX device
-#if CONFIG_D3D11VA
if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
On Fri, Apr 13, 2018 at 12:24 AM, Carl Eugen Hoyos wrote:
> 2018-04-13 0:11 GMT+02:00, Alexander Kravchenko :
>>
>>
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>>> Carl Eugen Hoyos
>>> Sent: Friday, April 13, 2018 12:48 AM
>>> To: FFmpeg development discussions and patches
>>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
>>> implementation by AMF encoder
>>>
>>> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko
>>> :
>>> >
>>> > This patch contains DXVA2 textures support implementation by AMF
>>> > encoder (in addition of D3D11 textures)
>>>
>>> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA
>
> (There is a linebreak in your original and my mail afaict.)
>
>>> > +if (frames_ctx->device_ctx->type ==
>>> > AV_HWDEVICE_TYPE_D3D11VA) {
>>>
>>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
>>>
>>> same below.
>>>
>>
>> Hi Carl, thanks for your feedback
>>
>> Could you explain the reason replacing
>> if (frames_ctx->device_ctx->type ==
>> to
>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==
>
> The code gets more readable / less ugly.
>
The code needs to be under an actual preprocessor check though, as the
types referenced in there may not be valid when D3D11 is not available
on the system.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl > Eugen Hoyos > Sent: Friday, April 13, 2018 1:24 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support > implementation by AMF encoder > > > The code gets more readable / less ugly. > Hi Carl, Is this the common practice? Any recommendations somewhere? IMHO it does not help reading code, but may confuse and make code researcher to spend time trying to figure out why the macro is in condition Also it makes condition longer Thanks, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
2018-04-13 0:11 GMT+02:00, Alexander Kravchenko :
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
>> Carl Eugen Hoyos
>> Sent: Friday, April 13, 2018 12:48 AM
>> To: FFmpeg development discussions and patches
>> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
>> implementation by AMF encoder
>>
>> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko
>> :
>> >
>> > This patch contains DXVA2 textures support implementation by AMF
>> > encoder (in addition of D3D11 textures)
>>
>> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA
(There is a linebreak in your original and my mail afaict.)
>> > +if (frames_ctx->device_ctx->type ==
>> > AV_HWDEVICE_TYPE_D3D11VA) {
>>
>> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
>>
>> same below.
>>
>
> Hi Carl, thanks for your feedback
>
> Could you explain the reason replacing
> if (frames_ctx->device_ctx->type ==
> to
> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==
The code gets more readable / less ugly.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl
> Eugen Hoyos
> Sent: Friday, April 13, 2018 12:48 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support
> implementation by AMF encoder
>
> 2018-04-12 23:42 GMT+02:00, Alexander Kravchenko :
> >
> > This patch contains DXVA2 textures support implementation by AMF
> > encoder (in addition of D3D11 textures)
>
> > +if (frames_ctx->device_ctx->hwctx) { #if CONFIG_D3D11VA
> > +if (frames_ctx->device_ctx->type ==
> > AV_HWDEVICE_TYPE_D3D11VA) {
>
> if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
>
> same below.
>
Hi Carl, thanks for your feedback
Could you explain the reason replacing
if (frames_ctx->device_ctx->type ==
to
if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==
in code like:
#if CONFIG_DXVA2
#include "libavutil/hwcontext_dxva2.h"
#endif
//...
#if CONFIG_D3D11VA
if (frames_ctx->device_ctx->type ==...
//code required include libavutil/hwcontext_dxva2.h"
#endif
Thanks,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
2018-04-12 23:42 GMT+02:00, Alexander Kravchenko :
>
> This patch contains DXVA2 textures support implementation
> by AMF encoder (in addition of D3D11 textures)
> +if (frames_ctx->device_ctx->hwctx) {
> +#if CONFIG_D3D11VA
> +if (frames_ctx->device_ctx->type ==
> AV_HWDEVICE_TYPE_D3D11VA) {
if (CONFIG_D3D11VA && frames_ctx->device_ctx->type ==...
same below.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder
This patch contains DXVA2 textures support implementation by AMF encoder (in
addition of D3D11 textures)
Samples of usage:
DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i
input.mp4 -an -c:v h264_amf out.mkv
D3D11va decoder -> d3d11 texture -> AMF Encoder:
ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i
input.mp4 -an -c:v h264_amf out.mkv
---
libavcodec/amfenc.c | 123 +++-
1 file changed, 102 insertions(+), 21 deletions(-)
diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index b9418b6791..c1f65f909d 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -24,6 +24,9 @@
#if CONFIG_D3D11VA
#include "libavutil/hwcontext_d3d11va.h"
#endif
+#if CONFIG_DXVA2
+#include "libavutil/hwcontext_dxva2.h"
+#endif
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
#include "libavutil/time.h"
@@ -50,6 +53,9 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
AV_PIX_FMT_YUV420P,
#if CONFIG_D3D11VA
AV_PIX_FMT_D3D11,
+#endif
+#if CONFIG_DXVA2
+AV_PIX_FMT_DXVA2_VLD,
#endif
AV_PIX_FMT_NONE
};
@@ -69,6 +75,7 @@ static const FormatMap format_map[] =
{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
{ AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 },
+{ AV_PIX_FMT_DXVA2_VLD, AMF_SURFACE_NV12 },
};
@@ -152,6 +159,23 @@ static int amf_load_library(AVCodecContext *avctx)
return 0;
}
+static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr,
IDirect3DDevice9 **device, void *avcl)
+{
+HRESULT hr;
+HANDLE device_handle;
+
+if (SUCCEEDED(devmgr->lpVtbl->OpenDeviceHandle(devmgr, &device_handle))) {
+if (SUCCEEDED(devmgr->lpVtbl->LockDevice(devmgr, device_handle,
device, FALSE))) {
+devmgr->lpVtbl->UnlockDevice(devmgr, device_handle, FALSE);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to lock device handle for
Direct3D9 device: %lx.\n", (unsigned long)hr);
+}
+devmgr->lpVtbl->CloseDeviceHandle(devmgr, device_handle);
+} else {
+av_log(avcl, AV_LOG_INFO, "Failed to open device handle for Direct3D9
device: %lx.\n", (unsigned long)hr);
+}
+}
+
static int amf_init_context(AVCodecContext *avctx)
{
AmfContext *ctx = avctx->priv_data;
@@ -177,34 +201,58 @@ static int amf_init_context(AVCodecContext *avctx)
res = ctx->factory->pVtbl->CreateContext(ctx->factory, &ctx->context);
AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "CreateContext()
failed with error %d\n", res);
// try to reuse existing DX device
-#if CONFIG_D3D11VA
if (avctx->hw_frames_ctx) {
-AVHWFramesContext *device_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
-if (device_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
-if (amf_av_to_amf_format(device_ctx->sw_format) !=
AMF_SURFACE_UNKNOWN) {
-if (device_ctx->device_ctx->hwctx) {
-AVD3D11VADeviceContext *device_d3d11 =
(AVD3D11VADeviceContext *)device_ctx->device_ctx->hwctx;
+AVHWFramesContext *frames_ctx =
(AVHWFramesContext*)avctx->hw_frames_ctx->data;
+if (amf_av_to_amf_format(frames_ctx->sw_format) !=
AMF_SURFACE_UNKNOWN) {
+if (frames_ctx->device_ctx->hwctx) {
+#if CONFIG_D3D11VA
+if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
+AVD3D11VADeviceContext *device_d3d11 =
(AVD3D11VADeviceContext *)frames_ctx->device_ctx->hwctx;
res = ctx->context->pVtbl->InitDX11(ctx->context,
device_d3d11->device, AMF_DX11_1);
if (res == AMF_OK) {
ctx->hw_frames_ctx =
av_buffer_ref(avctx->hw_frames_ctx);
if (!ctx->hw_frames_ctx) {
return AVERROR(ENOMEM);
}
-if (device_ctx->initial_pool_size > 0)
-ctx->hwsurfaces_in_queue_max =
device_ctx->initial_pool_size - 1;
+if (frames_ctx->initial_pool_size > 0)
+ctx->hwsurfaces_in_queue_max =
frames_ctx->initial_pool_size - 1;
} else {
-if(res == AMF_NOT_SUPPORTED)
+if (res == AMF_NOT_SUPPORTED)
av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx
has D3D11 device which doesn't have D3D11VA interface, switching to default\n");
else
av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx
has non-AMD device, switching to default\n");
}
}
-} else {
-av_log(avctx, AV_LOG_INFO, "avctx->hw_frames_ctx has format
not uspported by AMF, switching to default\n");
+#endif
+#if CONFIG_D
