Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-27 4:24 GMT+01:00 James Almer :
> On 11/27/2017 12:17 AM, Carl Eugen Hoyos wrote:

>> That's completely apart from the fact that this header file does
>> not comply with any style guide while Nvidia's does (from a
>> very quick look at both files).
>
> That would be because the Nvidia one was written/adapted by
> a ffmpeg developer, who probably paid attention to that.

(How is that related?)

> We can ask Mironov to improve the style in the header he
> submitted if that's important.

Not if you feel it is not important.

If everybody wants this header, I will try hard to abstain from
this discussion from now on.

Sorry, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[James Almer]

On 11/27/2017 12:17 AM, Carl Eugen Hoyos wrote:
> 2017-11-27 4:00 GMT+01:00 James Almer :
>> On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
>>> 2017-11-27 3:42 GMT+01:00 James Almer :
>>>
 No comments about the code, but given this patchset has started a policy
 controversy I'll state I'm in favor of including this external header.
>>>
>>> Will the header work for operating systems other than Windows?
>>
>> Why are you asking me? I'm not the author of the patch.
>>
>> And a quick look at the configure change should answer your question.
> 
> What I meant was:
> The header currently does not help a relevant number of users
> (it would make Zeranoe's and Hendrik's life a little easier, that's
> all). In the future, it will be useful because AMD plans to provide
> a Linux driver. But I have a feeling that the current header will
> not work for this future driver, meaning adding the header now
> may be counter-productive.

It can easily be adapted for that alongside the configure checks, I'm
sure, much like the Nvidia one was for different needs.

> 
> That's completely apart from the fact that this header file does
> not comply with any style guide while Nvidia's does (from a
> very quick look at both files).

That would be because the Nvidia one was written/adapted by a ffmpeg
developer, who probably paid attention to that.
We can ask Mironov to improve the style in the header he submitted if
that's important.

The avxsynth headers don't follow any style guide either, for that
matter. Indentation is all over the place.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 10:20 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 2017-11-27 4:06 GMT+01:00 Mironov, Mikhail
> :
> 
> > I think as a side affect we can help integrate Vulkan acceleration to 
> > FFmpeg.
> > It is much better then OpenCL for multimedia from performance
> perspective.
> 
> Why did I so strongly expect this argument?
> (I have neither ever used OpenCL nor Vulkan.)
> 
> Others may (and hopefully do) disagree but I believe you should really
> change your argumentation.
> 

I stated that this is a side note, not an argument.
Thank,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-27 4:06 GMT+01:00 Mironov, Mikhail :

> I think as a side affect we can help integrate Vulkan acceleration to FFmpeg.
> It is much better then OpenCL for multimedia from performance perspective.

Why did I so strongly expect this argument?
(I have neither ever used OpenCL nor Vulkan.)

Others may (and hopefully do) disagree but I believe
you should really change your argumentation.

Sorry, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-27 4:00 GMT+01:00 James Almer :
> On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
>> 2017-11-27 3:42 GMT+01:00 James Almer :
>>
>>> No comments about the code, but given this patchset has started a policy
>>> controversy I'll state I'm in favor of including this external header.
>>
>> Will the header work for operating systems other than Windows?
>
> Why are you asking me? I'm not the author of the patch.
>
> And a quick look at the configure change should answer your question.

What I meant was:
The header currently does not help a relevant number of users
(it would make Zeranoe's and Hendrik's life a little easier, that's
all). In the future, it will be useful because AMD plans to provide
a Linux driver. But I have a feeling that the current header will
not work for this future driver, meaning adding the header now
may be counter-productive.

That's completely apart from the fact that this header file does
not comply with any style guide while Nvidia's does (from a
very quick look at both files).

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: November 26, 2017 9:57 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 2017-11-27 3:42 GMT+01:00 James Almer :
> 
> > No comments about the code, but given this patchset has started a
> > policy controversy I'll state I'm in favor of including this external 
> > header.
> 
> Will the header work for operating systems other than Windows?

We are working on Linux version. Before I started FFmpeg integration 
I convinced the management to allocate resources.
It will come in two phases: 
1. AMF via Vulkan on Windows
2. AMF via Vulkan on Linux
I think as a side affect we can help integrate Vulkan acceleration to FFmpeg. 
It is much better then OpenCL for multimedia from performance perspective.

Thank,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-27 3:48 GMT+01:00 Philip Langdale :

[...]

Unrelated to this topic:
Please cut your quotes, I believe this is not the first message
where your content is very difficult to find.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[James Almer]

On 11/26/2017 11:57 PM, Carl Eugen Hoyos wrote:
> 2017-11-27 3:42 GMT+01:00 James Almer :
> 
>> No comments about the code, but given this patchset has started a policy
>> controversy I'll state I'm in favor of including this external header.
> 
> Will the header work for operating systems other than Windows?

Why are you asking me? I'm not the author of the patch.

And a quick look at the configure change should answer your question.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-27 3:42 GMT+01:00 James Almer :

> No comments about the code, but given this patchset has started a policy
> controversy I'll state I'm in favor of including this external header.

Will the header work for operating systems other than Windows?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[James Almer]

On 11/26/2017 11:36 PM, mmironov wrote:
> From 21d99252fad543d3d27a015912c0458b6ae11e08 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
>  SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|1 +
>  compat/amd/amfsdkenc.h   | 1755 
> ++
>  configure|   20 +-
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  602 
>  libavcodec/amfenc.h  |  143 
>  libavcodec/amfenc_h264.c |  397 +++
>  libavcodec/amfenc_hevc.c |  327 +
>  9 files changed, 3249 insertions(+), 2 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c

No comments about the code, but given this patchset has started a policy
controversy I'll state I'm in favor of including this external header.

Not shipping this one for having a working external version but shipping
the Nvidia one for being a custom working version of the unusable shit
they made public is rewarding them for said user unfriendliness, as Mark
clearly stated in a previous thread.
So lets add this one, then figure out if we want any of them at all or
not at a later point. They all can be moved to some external repository
if needed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> 
> A few minor fixups below.  I would be happy to apply this if it didn't contain
> the external header.
> 
> Thanks,
> 
> - Mark
> 
> 

I will resubmit the changes you mentioned. 
As of header inclusion issue I've sent a separate email.

Thanks,
Mikhail

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 22/11/17 23:28, mmironov wrote:
> From c669277afd764903d3da09d92a263d0fb58e24b1 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
>  SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|1 +
>  compat/amd/amfsdkenc.h   | 1755 
> ++
>  configure|   18 +-
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  596 
>  libavcodec/amfenc.h  |  143 
>  libavcodec/amfenc_h264.c |  397 +++
>  libavcodec/amfenc_hevc.c |  327 +
>  9 files changed, 3242 insertions(+), 1 deletion(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c

A few minor fixups below.  I would be happy to apply this if it didn't contain 
the external header.

Thanks,

- Mark


> diff --git a/Changelog b/Changelog
> index 68829f2..e5e5ffd 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -15,6 +15,7 @@ version :
>  - Raw aptX muxer and demuxer
>  - NVIDIA NVDEC-accelerated H.264, HEVC and VP9 hwaccel decoding
>  - Intel QSV-accelerated overlay filter
> +- AMD NW H.264 and HEVC encoders

NW?

>  
>  
>  version 3.4:
> diff --git a/compat/amd/amfsdkenc.h b/compat/amd/amfsdkenc.h
> new file mode 100644
> index 000..282656d
> --- /dev/null
> +++ b/compat/amd/amfsdkenc.h
> @@ -0,0 +1,1755 @@
> ...
> diff --git a/configure b/configure
> index 3788f26..a562a2a 100755
> --- a/configure
> +++ b/configure
> @@ -303,6 +303,7 @@ External library support:
>--disable-zlib   disable zlib [autodetect]
>  
>The following libraries provide various hardware acceleration features:
> +  --disable-amfdisable AMF video encoding code [autodetect]
>--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
>--disable-cuda   disable dynamically linked Nvidia CUDA code 
> [autodetect]
>--enable-cuda-sdkenable CUDA features that require the CUDA SDK 
> [no]
> @@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
>  "
>  
>  HWACCEL_AUTODETECT_LIBRARY_LIST="
> +amf
>  audiotoolbox
>  crystalhd
>  cuda
> @@ -2781,12 +2783,15 @@ scale_npp_filter_deps="cuda libnpp"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>  
> +amf_deps_any="libdl LoadLibrary"
> +
>  nvenc_deps="cuda"
>  nvenc_deps_any="libdl LoadLibrary"
>  nvenc_encoder_deps="nvenc"
>  
>  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
> +h264_amf_encoder_deps="amf"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
>  h264_cuvid_decoder_deps="cuvid"
>  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
> @@ -2803,6 +2808,7 @@ 
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
>  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
>  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
> +hevc_amf_encoder_deps="amf"
>  hevc_cuvid_decoder_deps="cuvid"
>  hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
>  hevc_mediacodec_decoder_deps="mediacodec"
> @@ -6164,9 +6170,12 @@ if enabled x86; then
>  mingw32*|mingw64*|win32|win64|linux|cygwin*)
>  ;;
>  *)
> -disable cuda cuvid nvdec nvenc
> +disable cuda cuvid nvdec nvenc amf
>  ;;
>  esac
> +if test $target_os = "linux"; then
> +disable amf
> +fi
>  else
>  disable cuda cuvid nvdec nvenc

amf here too?

>  fi
> @@ -6179,6 +6188,13 @@ void f(void) { struct { const GUID guid; } s[] = { { 
> NV_ENC_PRESET_HQ_GUID } };
>  int main(void) { return 0; }
>  EOF
>  
> +enabled amf &&
> +check_cc -I$source_path < +#include "compat/amd/amfsdkenc.h"
> +AMFFactory *factory;
> +int main(void) { return 0; }
> +EOF
> +
>  # Funny iconv installations are not unusual, so check it after all flags 
> have been set
>  if enabled libc_iconv; then
>  check_func_headers iconv.h iconv
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 2476aec..9bbb60e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -55,6 +55,7 @@ OBJS = ac3_parser.o 
> \
>  OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
>  OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
>  OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o mpeg4audio.o
> +OBJS-$(CONFIG_AMF) += amfenc.o
>  OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
>  OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
>  OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
> @@ -332,6 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-23 2:15 GMT+01:00 Marton Balint :

> All your points apply to Nvidia external headers as well

The Nvidia driver works on Linux where self-compilation is
at least not unusual.

Self compiled binaries by Windows users are very rare,
the one script that is typically used in that already rare
case could easily download the necessary header.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-11-22 23:36 GMT+01:00 Timo Rothenpieler :

> Also, I don't see a problem with including this AMD header. It very much
> increases the accessibility and maintainability

> (no need to watch out for potential breaking upstream changes, however
> likely that might be).

If we integrate the header, would that mean that FFmpeg developers have
to watch out more for potential upstream break or less?
(I believe a different answer than yours is at least possible.)

> Having those vendor-specific hwaccels enabled in otherwise generic
> builds gives a lot of people easy access, or access at all.

Could you elaborate?
Who exactly would get access in this case?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Marton Balint]

On Wed, 22 Nov 2017, Mark Thompson wrote:


On 22/11/17 22:53, Philip Langdale wrote:

On Wed, 22 Nov 2017 23:36:23 +0100
Timo Rothenpieler  wrote:


I'd like to look through it again and test a bit more (will try to
do so tomorrow, certainly by the end of the week), but I think it
should be ready to commit with the external header removed. 


Are you planning to remove Nvidia headers as well? 


No, I am very much against this.
And others have also voiced against that.

Also, I don't see a problem with including this AMD header. It very
much increases the accessibility and maintainability(no need to watch
out for potential breaking upstream changes, however likely that
might be). Having those vendor-specific hwaccels enabled in otherwise
generic builds gives a lot of people easy access, or access at all.

It also might make them potential usage candidates for browsers, no
idea how their weird lawyer-code-review system works though, and if
it has any impact to avoid external dependencies.



I feel the same way; I'm fine with the header in-tree.


Well, why should this external header be in the ffmpeg tree?

In my opinion indiscriminately placing upstream headers in the tree is just not 
what we want to do:
* It increases the maintenance burden, because upstream changes need to be 
checked and then reflected locally.
* Breaking changes are completely fatal - we have to choose one side or the 
other of the change and abandon the other completely.
* It makes it harder for users to build against different versions which they 
may have (especially for users who may want to stick with older versions they 
have verified for their use-cases).
* It makes it harder to developers to modify code on either side of the API, 
because more places have to be updated.

And what is the benefit?  A minor convenience gain for users who can't be 
bothered to get the headers themselves in the same way that they do for every 
other external package they use.  I don't think that's worth it.

(For comparison, including the Nvidia headers allows the stuff there to be 
built at all in the face of a hostile upstream.  That's quite different to a 
minor convenience gain.)


All your points apply to Nvidia external headers as well, and you can't 
set aside the fact that AMD and Nvidia deserve equal treatment. IMHO we 
either include the AMD headers, or we remove the Nvidia headers and make 
the configure error message point the user to an external github repo from 
where the Nvidia headers are downloadable.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 22/11/17 22:53, Philip Langdale wrote:
> On Wed, 22 Nov 2017 23:36:23 +0100
> Timo Rothenpieler  wrote:
> 
 I'd like to look through it again and test a bit more (will try to
 do so tomorrow, certainly by the end of the week), but I think it
 should be ready to commit with the external header removed.  
>>>
>>> Are you planning to remove Nvidia headers as well?  
>>
>> No, I am very much against this.
>> And others have also voiced against that.
>>
>> Also, I don't see a problem with including this AMD header. It very
>> much increases the accessibility and maintainability(no need to watch
>> out for potential breaking upstream changes, however likely that
>> might be). Having those vendor-specific hwaccels enabled in otherwise
>> generic builds gives a lot of people easy access, or access at all.
>>
>> It also might make them potential usage candidates for browsers, no
>> idea how their weird lawyer-code-review system works though, and if
>> it has any impact to avoid external dependencies.
>>
> 
> I feel the same way; I'm fine with the header in-tree.

Well, why should this external header be in the ffmpeg tree?

In my opinion indiscriminately placing upstream headers in the tree is just not 
what we want to do:
* It increases the maintenance burden, because upstream changes need to be 
checked and then reflected locally.
* Breaking changes are completely fatal - we have to choose one side or the 
other of the change and abandon the other completely.
* It makes it harder for users to build against different versions which they 
may have (especially for users who may want to stick with older versions they 
have verified for their use-cases).
* It makes it harder to developers to modify code on either side of the API, 
because more places have to be updated.

And what is the benefit?  A minor convenience gain for users who can't be 
bothered to get the headers themselves in the same way that they do for every 
other external package they use.  I don't think that's worth it.

(For comparison, including the Nvidia headers allows the stuff there to be 
built at all in the face of a hostile upstream.  That's quite different to a 
minor convenience gain.)

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Timo Rothenpieler
> Sent: November 22, 2017 5:36 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> Am 17.11.2017 um 06:07 schrieb mmironov:
> >  From 454aad17fea28e8e4c5abb904341181271971bfc Mon Sep 17 00:00:00
> > 2001
> > From: mmironov 
> > Date: Tue, 14 Nov 2017 17:54:24 -0500
> > Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs
> based on AMF
> >   SDK
> >
> > Signed-off-by: mmironov 
> > ---
> >   Changelog|1 +
> >   compat/amd/amfsdkenc.h   | 1755
> ++
> >   configure|   25 +
> >   libavcodec/Makefile  |4 +
> >   libavcodec/allcodecs.c   |2 +
> >   libavcodec/amfenc.c  |  596 
> >   libavcodec/amfenc.h  |  143 
> >   libavcodec/amfenc_h264.c |  397 +++
> >   libavcodec/amfenc_hevc.c |  327 +
> >   9 files changed, 3250 insertions(+)
> >   create mode 100644 compat/amd/amfsdkenc.h
> >   create mode 100644 libavcodec/amfenc.c
> >   create mode 100644 libavcodec/amfenc.h
> >   create mode 100644 libavcodec/amfenc_h264.c
> >   create mode 100644 libavcodec/amfenc_hevc.c
> ...
> > diff --git a/configure b/configure
> > index 3788f26..cbec01f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -303,6 +303,7 @@ External library support:
> > --disable-zlib   disable zlib [autodetect]
> >
> > The following libraries provide various hardware acceleration features:
> > +  --disable-amfdisable AMF video encoding code [autodetect]
> > --disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
> > --disable-cuda   disable dynamically linked Nvidia CUDA code
> [autodetect]
> > --enable-cuda-sdkenable CUDA features that require the CUDA SDK
> [no]
> > @@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
> >   "
> >
> >   HWACCEL_AUTODETECT_LIBRARY_LIST="
> > +amf
> >   audiotoolbox
> >   crystalhd
> >   cuda
> > @@ -2781,12 +2783,15 @@ scale_npp_filter_deps="cuda libnpp"
> >   scale_cuda_filter_deps="cuda_sdk"
> >   thumbnail_cuda_filter_deps="cuda_sdk"
> >
> > +amf_deps_any="dlopen LoadLibrary"
> 
> This should be libdl, and not dlopen.
> Or rather just LoadLibrary, since it's Windows only? No idea how exactly
> cygwin works there.
> 

The actual code calls dlopen() and it in turn calls LoadLibrary(). 
In the future Linux support will be added. So I feel to change this to libdl 
but keep.
From the prev post: I will combine amf and nvidia cases.

Thanks,
Mikhail

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Philip Langdale]

On Wed, 22 Nov 2017 23:36:23 +0100
Timo Rothenpieler  wrote:

> >> I'd like to look through it again and test a bit more (will try to
> >> do so tomorrow, certainly by the end of the week), but I think it
> >> should be ready to commit with the external header removed.  
> > 
> > Are you planning to remove Nvidia headers as well?  
> 
> No, I am very much against this.
> And others have also voiced against that.
> 
> Also, I don't see a problem with including this AMD header. It very
> much increases the accessibility and maintainability(no need to watch
> out for potential breaking upstream changes, however likely that
> might be). Having those vendor-specific hwaccels enabled in otherwise
> generic builds gives a lot of people easy access, or access at all.
> 
> It also might make them potential usage candidates for browsers, no
> idea how their weird lawyer-code-review system works though, and if
> it has any impact to avoid external dependencies.
> 

I feel the same way; I'm fine with the header in-tree.

--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Timo Rothenpieler]

I'd like to look through it again and test a bit more (will try to do so
tomorrow, certainly by the end of the week), but I think it should be ready to
commit with the external header removed.


Are you planning to remove Nvidia headers as well?


No, I am very much against this.
And others have also voiced against that.

Also, I don't see a problem with including this AMD header. It very much 
increases the accessibility and maintainability(no need to watch out for 
potential breaking upstream changes, however likely that might be).
Having those vendor-specific hwaccels enabled in otherwise generic 
builds gives a lot of people easy access, or access at all.


It also might make them potential usage candidates for browsers, no idea 
how their weird lawyer-code-review system works though, and if it has 
any impact to avoid external dependencies.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Timo Rothenpieler]

Am 17.11.2017 um 06:07 schrieb mmironov:

 From 454aad17fea28e8e4c5abb904341181271971bfc Mon Sep 17 00:00:00 2001
From: mmironov 
Date: Tue, 14 Nov 2017 17:54:24 -0500
Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
  SDK

Signed-off-by: mmironov 
---
  Changelog|1 +
  compat/amd/amfsdkenc.h   | 1755 ++
  configure|   25 +
  libavcodec/Makefile  |4 +
  libavcodec/allcodecs.c   |2 +
  libavcodec/amfenc.c  |  596 
  libavcodec/amfenc.h  |  143 
  libavcodec/amfenc_h264.c |  397 +++
  libavcodec/amfenc_hevc.c |  327 +
  9 files changed, 3250 insertions(+)
  create mode 100644 compat/amd/amfsdkenc.h
  create mode 100644 libavcodec/amfenc.c
  create mode 100644 libavcodec/amfenc.h
  create mode 100644 libavcodec/amfenc_h264.c
  create mode 100644 libavcodec/amfenc_hevc.c

...

diff --git a/configure b/configure
index 3788f26..cbec01f 100755
--- a/configure
+++ b/configure
@@ -303,6 +303,7 @@ External library support:
--disable-zlib   disable zlib [autodetect]
  
The following libraries provide various hardware acceleration features:

+  --disable-amfdisable AMF video encoding code [autodetect]
--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
--disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
--enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
@@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
  "
  
  HWACCEL_AUTODETECT_LIBRARY_LIST="

+amf
  audiotoolbox
  crystalhd
  cuda
@@ -2781,12 +2783,15 @@ scale_npp_filter_deps="cuda libnpp"
  scale_cuda_filter_deps="cuda_sdk"
  thumbnail_cuda_filter_deps="cuda_sdk"
  
+amf_deps_any="dlopen LoadLibrary"


This should be libdl, and not dlopen.
Or rather just LoadLibrary, since it's Windows only? No idea how exactly 
cygwin works there.


Sorry for the double-post, was a bit too quick with that first mail.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Timo Rothenpieler]

Am 17.11.2017 um 06:07 schrieb mmironov:

 From 454aad17fea28e8e4c5abb904341181271971bfc Mon Sep 17 00:00:00 2001
From: mmironov 
Date: Tue, 14 Nov 2017 17:54:24 -0500
Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
  SDK

Signed-off-by: mmironov 
---
  Changelog|1 +
  compat/amd/amfsdkenc.h   | 1755 ++
  configure|   25 +
  libavcodec/Makefile  |4 +
  libavcodec/allcodecs.c   |2 +
  libavcodec/amfenc.c  |  596 
  libavcodec/amfenc.h  |  143 
  libavcodec/amfenc_h264.c |  397 +++
  libavcodec/amfenc_hevc.c |  327 +
  9 files changed, 3250 insertions(+)
  create mode 100644 compat/amd/amfsdkenc.h
  create mode 100644 libavcodec/amfenc.c
  create mode 100644 libavcodec/amfenc.h
  create mode 100644 libavcodec/amfenc_h264.c
  create mode 100644 libavcodec/amfenc_hevc.c


...

diff --git a/configure b/configure
index 3788f26..cbec01f 100755
--- a/configure
+++ b/configure
@@ -303,6 +303,7 @@ External library support:
--disable-zlib   disable zlib [autodetect]
  
The following libraries provide various hardware acceleration features:

+  --disable-amfdisable AMF video encoding code [autodetect]
--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
--disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
--enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
@@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
  "
  
  HWACCEL_AUTODETECT_LIBRARY_LIST="

+amf
  audiotoolbox
  crystalhd
  cuda
@@ -2781,12 +2783,15 @@ scale_npp_filter_deps="cuda libnpp"
  scale_cuda_filter_deps="cuda_sdk"
  thumbnail_cuda_filter_deps="cuda_sdk"
  
+amf_deps_any="dlopen LoadLibrary"

+
  nvenc_deps="cuda"
  nvenc_deps_any="libdl LoadLibrary"
  nvenc_encoder_deps="nvenc"
  
  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"

  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
+h264_amf_encoder_deps="amf"
  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
  h264_cuvid_decoder_deps="cuvid"
  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
@@ -2803,6 +2808,7 @@ h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
+hevc_amf_encoder_deps="amf"
  hevc_cuvid_decoder_deps="cuvid"
  hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
  hevc_mediacodec_decoder_deps="mediacodec"
@@ -6171,6 +6177,18 @@ else
  disable cuda cuvid nvdec nvenc
  fi
  
+if enabled x86; then

+case $target_os in
+mingw32*|mingw64*|win32|win64|cygwin*)
+;;
+*)
+disable amf
+;;
+esac
+else
+disable amf
+fi
+


Can't this be integrated into the nvenc case, that, except for also 
having linux, does pretty much the same?
Like, moving linux to its own case that only disables amf, and adding 
amf to the other two nvenc/cuvid/nvdec disable-lines.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 21, 2017 7:40 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On 21/11/17 23:08, Timo Rothenpieler wrote:
> > Am 21.11.2017 um 16:32 schrieb Mironov, Mikhail:
> >>
> >> Are you all busy right now? Any hint on timing?
> >> Thanks,
> >> Mikhail
> >
> > I cannot test this patch due to lack of hardware, but by now the code has
> been polished for a while, and if no further comments/issues come up, I'd be
> all for finally merging this.
> 
> I'd like to look through it again and test a bit more (will try to do so
> tomorrow, certainly by the end of the week), but I think it should be ready to
> commit with the external header removed.

Are you planning to remove Nvidia headers as well?

> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 21/11/17 23:08, Timo Rothenpieler wrote:
> Am 21.11.2017 um 16:32 schrieb Mironov, Mikhail:
>>
>> Are you all busy right now? Any hint on timing?
>> Thanks,
>> Mikhail
> 
> I cannot test this patch due to lack of hardware, but by now the code has 
> been polished for a while, and if no further comments/issues come up, I'd be 
> all for finally merging this.

I'd like to look through it again and test a bit more (will try to do so 
tomorrow, certainly by the end of the week), but I think it should be ready to 
commit with the external header removed.

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Timo Rothenpieler]

Am 21.11.2017 um 16:32 schrieb Mironov, Mikhail:

ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Are you all busy right now? Any hint on timing?
Thanks,
Mikhail


I cannot test this patch due to lack of hardware, but by now the code 
has been polished for a while, and if no further comments/issues come 
up, I'd be all for finally merging this.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Are you all busy right now? Any hint on timing?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 05:55:33PM -0500, mmironov wrote:
> From 643006c4be514dd513232f7438b17add2a763685 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 14 Nov 2017 17:54:24 -0500
> Subject: [PATCH] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF
>  SDK
> 
> Signed-off-by: mmironov 
[...]

> +if (ret = ff_alloc_packet2(avctx, pkt, size, 0) < 0) {

missing ()


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 14, 2017 6:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On 14/11/17 22:10, Mironov, Mikhail wrote:
> >> On 14/11/17 17:14, Mironov, Mikhail wrote:
> > +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> > + 
> >>> 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 (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) {
> 
>  This test is inverted.
> 
>  Have you actually tested this path?  Even with that test fixed,
>  I'm unable to pass the following initialisation test with an
>  AMD
>  D3D11
>  device.
> 
> >>>
> >>> Yes, the condition should be reverted. To test I had to add
> >>> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the
> command
>  line.
> >>
> >> Yeah.  I get:
> >>
> >> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
> >> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
> >> h264_amf
> >> out.mp4 ...
> >> [AVHWDeviceContext @ 0270e120] Created on device
> >> 1002:665f
> >> (AMD Radeon (TM) R7 360 Series).
> >> ...
> >> [h264_amf @ 004dcd80] amf_shared: avctx-
> >hw_frames_ctx
>  has
> >> non-AMD device, switching to default
> >>
> >> It's then comedically slow in this state (about 2fps), but works
> >> fine when the decode is in software.
> >
> > Is it possible that you also have iGPU not disabled and it is used
> > for
>  decoding as adapter 0?
> 
>  There is an integrated GPU, but it's currently completely disabled.
>  (I made
>    November/219795.html> to check that the device was definitely
>  right.)
> 
> > Can you provide a log from dxdiag.exe?
> 
>  
> 
> > If AMF created own DX device then submission logic an speed is the
> > same
>  as from SW decoder.
> > It would be interesting to see a short GPUVIEW log.
> 
>  My Windows knowledge is insufficient to get that immediately, but
>  if you think it's useful I can look into it?
> >>>
> >>> I think I know what is going on. You are on Win7. In Win7 D3D11VA
> >>> API is
> >> not available from MSFT.
> >>> AMF will fall into DX9 based encoding submission and this is why the
> >> message was produced.
> >>> The AMF performance should be the same on DX9 but I don’t know how
> >>> decoding is done without D3D11VA support.
> >>> GPUVIEW is not really needed if my assumptions are correct.
> >>
> >> Ah, that would make sense.  Maybe detect it and fail earlier with a
> >> helpful message - the current "not an AMD device" is wrong in this case.
> >>
> >> Decode via D3D11 does work for me on Windows 7 with both AMD and
> >> Intel; I don't know anything about how, though.  (I don't really care
> >> about Windows 7 - this was just a set of parts mashed together into a
> >> working machine for testing, the Windows 7 install is inherited from
> >> elsewhere.)
> >
> > I run this in Win7.  What I see is the decoding does go via D3D11VA.
> > The support comes with Platform Update. But AMF encoder works on Win7
> > via D3D9 only. That explains the performance hit: In D3D11 to copy video
> output HW accelerator copies frame via staging texture.
> > If I use for decoding DXVA2 it is faster because staging texture is not
> needed.
> > I am thinking to connect dxva2 acceleration with AMF encoder but
> > probably in the next phase.
> > I've added more precise logging.
> >
> >>
> > +{ "filler_data","Filler Data Enable",
> >> OFFSET(filler_data),
>  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "vbaq",   "Enable VBAQ",
>  OFFSET(enable_vbaq),
>  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "frame_skipping", "Rate Control Based Frame Skip",
>  OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE
> },
> > +
> > +/// QP Values
> > +{ "qp_i",   "Quantization Parameter for I-Frame",
>  OFFSET(qp_i),
>  AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> > +{ "qp_p",   "Quantization Parameter for P-Frame",
> 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 14/11/17 22:10, Mironov, Mikhail wrote:
>> On 14/11/17 17:14, Mironov, Mikhail wrote:
> +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> + 
>>> 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 (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) {

 This test is inverted.

 Have you actually tested this path?  Even with that test fixed,
 I'm unable to pass the following initialisation test with an AMD
 D3D11
 device.

>>>
>>> Yes, the condition should be reverted. To test I had to add
>>> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
 line.
>>
>> Yeah.  I get:
>>
>> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
>> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
>> h264_amf
>> out.mp4 ...
>> [AVHWDeviceContext @ 0270e120] Created on device
>> 1002:665f
>> (AMD Radeon (TM) R7 360 Series).
>> ...
>> [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
 has
>> non-AMD device, switching to default
>>
>> It's then comedically slow in this state (about 2fps), but works
>> fine when the decode is in software.
>
> Is it possible that you also have iGPU not disabled and it is used
> for
 decoding as adapter 0?

 There is an integrated GPU, but it's currently completely disabled.
 (I made
  to check that the device was definitely right.)

> Can you provide a log from dxdiag.exe?

 

> If AMF created own DX device then submission logic an speed is the
> same
 as from SW decoder.
> It would be interesting to see a short GPUVIEW log.

 My Windows knowledge is insufficient to get that immediately, but if
 you think it's useful I can look into it?
>>>
>>> I think I know what is going on. You are on Win7. In Win7 D3D11VA API is
>> not available from MSFT.
>>> AMF will fall into DX9 based encoding submission and this is why the
>> message was produced.
>>> The AMF performance should be the same on DX9 but I don’t know how
>>> decoding is done without D3D11VA support.
>>> GPUVIEW is not really needed if my assumptions are correct.
>>
>> Ah, that would make sense.  Maybe detect it and fail earlier with a helpful
>> message - the current "not an AMD device" is wrong in this case.
>>
>> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel;
>> I don't know anything about how, though.  (I don't really care about
>> Windows 7 - this was just a set of parts mashed together into a working
>> machine for testing, the Windows 7 install is inherited from elsewhere.)
> 
> I run this in Win7.  What I see is the decoding does go via D3D11VA. The 
> support comes 
> with Platform Update. But AMF encoder works on Win7 via D3D9 only. That 
> explains 
> the performance hit: In D3D11 to copy video output HW accelerator copies 
> frame via staging texture. 
> If I use for decoding DXVA2 it is faster because staging texture is not 
> needed.
> I am thinking to connect dxva2 acceleration with AMF encoder 
> but probably in the next phase.
> I've added more precise logging.
> 
>>
> +{ "filler_data","Filler Data Enable",
>> OFFSET(filler_data),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +{ "vbaq",   "Enable VBAQ",
 OFFSET(enable_vbaq),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +{ "frame_skipping", "Rate Control Based Frame Skip",
 OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +
> +/// QP Values
> +{ "qp_i",   "Quantization Parameter for I-Frame",
 OFFSET(qp_i),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +{ "qp_p",   "Quantization Parameter for P-Frame",
>> OFFSET(qp_p),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +{ "qp_b",   "Quantization Parameter for B-Frame",
>> OFFSET(qp_b),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +
> +/// Pre-Pass, Pre-Analysis, Two-Pass
> +{ "preanalysis","Pre-Analysis Mode",
>> OFFSET(preanalysis),
 AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
> +
> +/// Maximum Access Unit Size
> +{ "max_au_size","Maximum Access 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: November 14, 2017 5:32 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Tue, Nov 14, 2017 at 6:45 PM, Mark Thompson  wrote:
> >
> > Decode via D3D11 does work for me on Windows 7 with both AMD and
> > Intel; I don't know anything about how, though.  (I don't really care
> > about Windows 7 - this was just a set of parts mashed together into a
> > working machine for testing, the Windows 7 install is inherited from
> > elsewhere.)
> 
> Even with the platform update, D3D11 on Windows 7 does not support
> NV12 textures. All you could potentially decode into is the opaque format,
> but thats not much fun at all.
> 

I thought the same way but today I debugged FFmpeg on Win7 and saw that 
CreateTexture2D() with DXGI_FORMAT_NV12 succeeded and 
video device and context acquired.. 
I think some optional update requeued, though. 

> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Hendrik Leppkes]

On Tue, Nov 14, 2017 at 6:45 PM, Mark Thompson  wrote:
>
> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel; I 
> don't know anything about how, though.  (I don't really care about Windows 7 
> - this was just a set of parts mashed together into a working machine for 
> testing, the Windows 7 install is inherited from elsewhere.)

Even with the platform update, D3D11 on Windows 7 does not support
NV12 textures. All you could potentially decode into is the opaque
format, but thats not much fun at all.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> On 14/11/17 17:14, Mironov, Mikhail wrote:
> >>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> >>> + 
> > 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 (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) {
> >>
> >> This test is inverted.
> >>
> >> Have you actually tested this path?  Even with that test fixed,
> >> I'm unable to pass the following initialisation test with an AMD
> >> D3D11
> >> device.
> >>
> >
> > Yes, the condition should be reverted. To test I had to add
> > "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
> >> line.
> 
>  Yeah.  I get:
> 
>  $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
>  hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
> h264_amf
>  out.mp4 ...
>  [AVHWDeviceContext @ 0270e120] Created on device
> 1002:665f
>  (AMD Radeon (TM) R7 360 Series).
>  ...
>  [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
> >> has
>  non-AMD device, switching to default
> 
>  It's then comedically slow in this state (about 2fps), but works
>  fine when the decode is in software.
> >>>
> >>> Is it possible that you also have iGPU not disabled and it is used
> >>> for
> >> decoding as adapter 0?
> >>
> >> There is an integrated GPU, but it's currently completely disabled.
> >> (I made
> >>  >> November/219795.html> to check that the device was definitely right.)
> >>
> >>> Can you provide a log from dxdiag.exe?
> >>
> >> 
> >>
> >>> If AMF created own DX device then submission logic an speed is the
> >>> same
> >> as from SW decoder.
> >>> It would be interesting to see a short GPUVIEW log.
> >>
> >> My Windows knowledge is insufficient to get that immediately, but if
> >> you think it's useful I can look into it?
> >
> > I think I know what is going on. You are on Win7. In Win7 D3D11VA API is
> not available from MSFT.
> > AMF will fall into DX9 based encoding submission and this is why the
> message was produced.
> > The AMF performance should be the same on DX9 but I don’t know how
> > decoding is done without D3D11VA support.
> > GPUVIEW is not really needed if my assumptions are correct.
> 
> Ah, that would make sense.  Maybe detect it and fail earlier with a helpful
> message - the current "not an AMD device" is wrong in this case.
> 
> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel;
> I don't know anything about how, though.  (I don't really care about
> Windows 7 - this was just a set of parts mashed together into a working
> machine for testing, the Windows 7 install is inherited from elsewhere.)

I run this in Win7.  What I see is the decoding does go via D3D11VA. The 
support comes 
with Platform Update. But AMF encoder works on Win7 via D3D9 only. That 
explains 
the performance hit: In D3D11 to copy video output HW accelerator copies frame 
via staging texture. 
If I use for decoding DXVA2 it is faster because staging texture is not needed.
I am thinking to connect dxva2 acceleration with AMF encoder 
but probably in the next phase.
I've added more precise logging.

> 
> >>> +{ "filler_data","Filler Data Enable",
> OFFSET(filler_data),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "vbaq",   "Enable VBAQ",
> >> OFFSET(enable_vbaq),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "frame_skipping", "Rate Control Based Frame Skip",
> >> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +
> >>> +/// QP Values
> >>> +{ "qp_i",   "Quantization Parameter for I-Frame",
> >> OFFSET(qp_i),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +{ "qp_p",   "Quantization Parameter for P-Frame",
>  OFFSET(qp_p),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +{ "qp_b",   "Quantization Parameter for B-Frame",
>  OFFSET(qp_b),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +
> >>> +/// Pre-Pass, Pre-Analysis, Two-Pass
> >>> +{ "preanalysis","Pre-Analysis Mode",
>  OFFSET(preanalysis),
> >> AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
> >>> +
> >>> +/// Maximum Access Unit Size
> >>> +{ "max_au_size","Maximum Access Unit Size for rate control
> (in
>  bits)",
> >> OFFSET(max_au_size),  

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 13/11/17 23:09, mmironov wrote:
> From d6f467ec7f610f21f929f9c21f03af3cabe84cf2 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 7 Nov 2017 10:57:21 -0500
> Subject: [PATCH] Added HW accelerated H.264 and HEVC encoding for AMD
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|1 +
>  compat/amd/amfsdkenc.h   | 1755 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  590 
>  libavcodec/amfenc.h  |  143 
>  libavcodec/amfenc_h264.c |  397 +++
>  libavcodec/amfenc_hevc.c |  328 +
>  9 files changed, 3245 insertions(+)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> ...
> diff --git a/libavcodec/amfenc_h264.c b/libavcodec/amfenc_h264.c
> new file mode 100644
> index 000..cb606d2
> --- /dev/null
> +++ b/libavcodec/amfenc_h264.c
> ...
> +
> +{ "insert_aud","Inserts AU Delimiter NAL unit", 
> OFFSET(insert_aud),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +
> ...
> diff --git a/libavcodec/amfenc_hevc.c b/libavcodec/amfenc_hevc.c
> new file mode 100644
> index 000..d534310
> --- /dev/null
> +++ b/libavcodec/amfenc_hevc.c
> ...
> +
> +{ "insert_aud","Inserts AU Delimiter NAL unit", 
> OFFSET(insert_aud),AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE },

Please call it just "aud" to be consistent with other encoders (libx264, nvenc, 
vaapi).

Thanks,

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 14/11/17 17:14, Mironov, Mikhail wrote:
>>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, 
> 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 (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) {
>>
>> This test is inverted.
>>
>> Have you actually tested this path?  Even with that test fixed, I'm
>> unable to pass the following initialisation test with an AMD D3D11
>> device.
>>
>
> Yes, the condition should be reverted. To test I had to add
> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
>> line.

 Yeah.  I get:

 $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
 hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
 out.mp4 ...
 [AVHWDeviceContext @ 0270e120] Created on device 1002:665f
 (AMD Radeon (TM) R7 360 Series).
 ...
 [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
>> has
 non-AMD device, switching to default

 It's then comedically slow in this state (about 2fps), but works fine
 when the decode is in software.
>>>
>>> Is it possible that you also have iGPU not disabled and it is used for
>> decoding as adapter 0?
>>
>> There is an integrated GPU, but it's currently completely disabled.  (I made
>> > November/219795.html> to check that the device was definitely right.)
>>
>>> Can you provide a log from dxdiag.exe?
>>
>> 
>>
>>> If AMF created own DX device then submission logic an speed is the same
>> as from SW decoder.
>>> It would be interesting to see a short GPUVIEW log.
>>
>> My Windows knowledge is insufficient to get that immediately, but if you
>> think it's useful I can look into it?
> 
> I think I know what is going on. You are on Win7. In Win7 D3D11VA API is not 
> available from MSFT. 
> AMF will fall into DX9 based encoding submission and this is why the message 
> was produced.
> The AMF performance should be the same on DX9 but I don’t know how decoding 
> is done 
> without D3D11VA support.
> GPUVIEW is not really needed if my assumptions are correct. 

Ah, that would make sense.  Maybe detect it and fail earlier with a helpful 
message - the current "not an AMD device" is wrong in this case.

Decode via D3D11 does work for me on Windows 7 with both AMD and Intel; I don't 
know anything about how, though.  (I don't really care about Windows 7 - this 
was just a set of parts mashed together into a working machine for testing, the 
Windows 7 install is inherited from elsewhere.)

>>> +{ "filler_data","Filler Data Enable",   
>>> OFFSET(filler_data),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +{ "vbaq",   "Enable VBAQ",
>> OFFSET(enable_vbaq),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +{ "frame_skipping", "Rate Control Based Frame Skip",
>> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +
>>> +/// QP Values
>>> +{ "qp_i",   "Quantization Parameter for I-Frame",
>> OFFSET(qp_i),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +{ "qp_p",   "Quantization Parameter for P-Frame",
 OFFSET(qp_p),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +{ "qp_b",   "Quantization Parameter for B-Frame",
 OFFSET(qp_b),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +
>>> +/// Pre-Pass, Pre-Analysis, Two-Pass
>>> +{ "preanalysis","Pre-Analysis Mode",
 OFFSET(preanalysis),
>> AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
>>> +
>>> +/// Maximum Access Unit Size
>>> +{ "max_au_size","Maximum Access Unit Size for rate control (in
 bits)",
>> OFFSET(max_au_size),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX,
>> VE
 },
>>
>> Can you explain more about what this option does?  I don't seem to
>> be able to get it to do anything - e.g. setting -max_au_size 8
>> with 30fps CBR 1M (which should be easily achievable) still makes
>> packets of more than 8
>> bits.)
>>
>
> It means maximum frame size in bits, and it should be used together
> with enforce_hrd enabled.  I tested, it works after the related fix
> for
 enforce_hrd.
> I added  dependency handling.

 $ ./ffmpeg_g -y -nostats -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
 -bsf:v trace_headers -frames:v 1000 -enforce_hrd 1 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> > +res = ctx->factory->pVtbl->CreateContext(ctx->factory, 
> >>> 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 (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) {
> 
>  This test is inverted.
> 
>  Have you actually tested this path?  Even with that test fixed, I'm
>  unable to pass the following initialisation test with an AMD D3D11
> device.
> 
> >>>
> >>> Yes, the condition should be reverted. To test I had to add
> >>> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
> line.
> >>
> >> Yeah.  I get:
> >>
> >> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
> >> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
> >> out.mp4 ...
> >> [AVHWDeviceContext @ 0270e120] Created on device 1002:665f
> >> (AMD Radeon (TM) R7 360 Series).
> >> ...
> >> [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
> has
> >> non-AMD device, switching to default
> >>
> >> It's then comedically slow in this state (about 2fps), but works fine
> >> when the decode is in software.
> >
> > Is it possible that you also have iGPU not disabled and it is used for
> decoding as adapter 0?
> 
> There is an integrated GPU, but it's currently completely disabled.  (I made
>  November/219795.html> to check that the device was definitely right.)
> 
> > Can you provide a log from dxdiag.exe?
> 
> 
> 
> > If AMF created own DX device then submission logic an speed is the same
> as from SW decoder.
> > It would be interesting to see a short GPUVIEW log.
> 
> My Windows knowledge is insufficient to get that immediately, but if you
> think it's useful I can look into it?

I think I know what is going on. You are on Win7. In Win7 D3D11VA API is not 
available from MSFT. 
AMF will fall into DX9 based encoding submission and this is why the message 
was produced.
The AMF performance should be the same on DX9 but I don’t know how decoding is 
done 
without D3D11VA support.
GPUVIEW is not really needed if my assumptions are correct. 

> 
> > +
> > +// Dynamic
> > +/// Rate Control Method
> > +{ "rc", "Rate Control Method",
>  OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =
> 
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
>  R},
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,
> 
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
>  _VBR, VE, "rc" },
> > +{ "cqp","Constant Quantization Parameter",  0,
>  AV_OPT_TYPE_CONST, { .i64 =
>  AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP
> >> },
>  0, 0, VE, "rc" },
> > +{ "cbr","Constant Bitrate", 0,
>  AV_OPT_TYPE_CONST, { .i64 =
>  AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0,
> 0,
>  VE, "rc" },
> > +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
>  AV_OPT_TYPE_CONST, { .i64 =
> 
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
>  R}, 0, 0, VE, "rc" },
> > +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
>  AV_OPT_TYPE_CONST, { .i64 =
> 
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
>  _VBR }, 0, 0, VE, "rc" },
> 
>  I think the default for this option needs to be decided dynamically.
>  Just setting "-b:v" is a not-unreasonable thing to do, and
>  currently the choice of PEAK_CONSTRAINED_VBR makes it then
> complain
>  that
> >> maxrate isn't set.
>  Similarly, if the only setting is some constant-quality option
>  (-q/- global_quality, or your private ones below), it ignores that
>  and use the default 2Mbps instead.
> 
> > +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
> > +{ "enforce_hrd","Enforce HRD",
> >> OFFSET(enforce_hrd),
>  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> 
>  Does this option work?  I don't seem to be able to push it into
>  generating HRD information with any combination of options.
> 
> >>>
> >>> Fixed.
> >>
> >> What combination of options are needed to get the HRD parameters in
> >> the output stream?  I still don't see them with the new version.
> >
> > From codec team: AMF HRD parameter ensures that the output stream is
> > conformant to HRD bit rate requirements but does not add SEI any other
> stream parameters.
> 
> Ok, sure.
> 
> > +{ "filler_data",  

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 14/11/17 15:51, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: November 14, 2017 9:14 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
>> GPUs based on AMF SDK
>>
>> On 13/11/17 23:00, Mironov, Mikhail wrote:
> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, 
>>> 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 (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) {

 This test is inverted.

 Have you actually tested this path?  Even with that test fixed, I'm
 unable to pass the following initialisation test with an AMD D3D11 device.

>>>
>>> Yes, the condition should be reverted. To test I had to add "-hwaccel
>>> d3d11va -hwaccel_output_format d3d11" to the command line.
>>
>> Yeah.  I get:
>>
>> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
>> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
>> out.mp4 ...
>> [AVHWDeviceContext @ 0270e120] Created on device 1002:665f
>> (AMD Radeon (TM) R7 360 Series).
>> ...
>> [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx has
>> non-AMD device, switching to default
>>
>> It's then comedically slow in this state (about 2fps), but works fine when 
>> the
>> decode is in software.
> 
> Is it possible that you also have iGPU not disabled and it is used for 
> decoding as adapter 0?

There is an integrated GPU, but it's currently completely disabled.  (I made 
 to 
check that the device was definitely right.)

> Can you provide a log from dxdiag.exe?



> If AMF created own DX device then submission logic an speed is the same as 
> from SW decoder. 
> It would be interesting to see a short GPUVIEW log.

My Windows knowledge is insufficient to get that immediately, but if you think 
it's useful I can look into it?

> +
> +// Dynamic
> +/// Rate Control Method
> +{ "rc", "Rate Control Method",
 OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =

>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
 R}, AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,

>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
 _VBR, VE, "rc" },
> +{ "cqp","Constant Quantization Parameter",  0,
 AV_OPT_TYPE_CONST, { .i64 =
 AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP
>> },
 0, 0, VE, "rc" },
> +{ "cbr","Constant Bitrate", 0,
 AV_OPT_TYPE_CONST, { .i64 =
 AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0, 0,
 VE, "rc" },
> +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
 AV_OPT_TYPE_CONST, { .i64 =

>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
 R}, 0, 0, VE, "rc" },
> +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
 AV_OPT_TYPE_CONST, { .i64 =

>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
 _VBR }, 0, 0, VE, "rc" },

 I think the default for this option needs to be decided dynamically.
 Just setting "-b:v" is a not-unreasonable thing to do, and currently
 the choice of PEAK_CONSTRAINED_VBR makes it then complain that
>> maxrate isn't set.
 Similarly, if the only setting is some constant-quality option (-q/-
 global_quality, or your private ones below), it ignores that and use
 the default 2Mbps instead.

> +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
> +{ "enforce_hrd","Enforce HRD",
>> OFFSET(enforce_hrd),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },

 Does this option work?  I don't seem to be able to push it into
 generating HRD information with any combination of options.

>>>
>>> Fixed.
>>
>> What combination of options are needed to get the HRD parameters in the
>> output stream?  I still don't see them with the new version.
> 
> From codec team: AMF HRD parameter ensures that the output stream is 
> conformant 
> to HRD bit rate requirements but does not add SEI any other stream 
> parameters. 

Ok, sure.

> +{ "filler_data","Filler Data Enable",   
> OFFSET(filler_data),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +{ "vbaq",   "Enable VBAQ",  
> OFFSET(enable_vbaq),
 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mironov, Mikhail
> Sent: November 14, 2017 10:51 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Mark Thompson
> > Sent: November 14, 2017 9:14 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> > GPUs based on AMF SDK
> >
> > On 13/11/17 23:00, Mironov, Mikhail wrote:
> > >>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, 
> > >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 (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) {
> > >>
> > >> This test is inverted.
> > >>
> > >> Have you actually tested this path?  Even with that test fixed, I'm
> > >> unable to pass the following initialisation test with an AMD D3D11
> device.
> > >>
> > >
> > > Yes, the condition should be reverted. To test I had to add
> > > "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
> line.
> >
> > Yeah.  I get:
> >
> > $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
> > hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
> > out.mp4 ...
> > [AVHWDeviceContext @ 0270e120] Created on device 1002:665f
> > (AMD Radeon (TM) R7 360 Series).
> > ...
> > [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx has
> > non-AMD device, switching to default
> >
> > It's then comedically slow in this state (about 2fps), but works fine
> > when the decode is in software.
> 
> Is it possible that you also have iGPU not disabled and it is used for 
> decoding
> as adapter 0?
> Can you provide a log from dxdiag.exe?
> If AMF created own DX device then submission logic an speed is the same as
> from SW decoder.
> It would be interesting to see a short GPUVIEW log.
> 
> >
> > >>> +
> > >>> +// Dynamic
> > >>> +/// Rate Control Method
> > >>> +{ "rc", "Rate Control Method",
> > >> OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =
> > >>
> >
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> > >> R},
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,
> > >>
> >
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> > >> _VBR, VE, "rc" },
> > >>> +{ "cqp","Constant Quantization Parameter",  0,
> > >> AV_OPT_TYPE_CONST, { .i64 =
> > >> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP
> > },
> > >> 0, 0, VE, "rc" },
> > >>> +{ "cbr","Constant Bitrate", 0,
> > >> AV_OPT_TYPE_CONST, { .i64 =
> > >> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0,
> 0,
> > >> VE, "rc" },
> > >>> +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
> > >> AV_OPT_TYPE_CONST, { .i64 =
> > >>
> >
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> > >> R}, 0, 0, VE, "rc" },
> > >>> +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
> > >> AV_OPT_TYPE_CONST, { .i64 =
> > >>
> >
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> > >> _VBR }, 0, 0, VE, "rc" },
> > >>
> > >> I think the default for this option needs to be decided dynamically.
> > >> Just setting "-b:v" is a not-unreasonable thing to do, and
> > >> currently the choice of PEAK_CONSTRAINED_VBR makes it then
> complain
> > >> that
> > maxrate isn't set.
> > >> Similarly, if the only setting is some constant-quality option
> > >> (-q/- global_quality, or your private ones below), it ignores that
> > >> and use the default 2Mbps instead.
> > >>
> > >>> +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
> > >>> +{ "enforce_hrd","Enforce HRD",
> > OFFSET(enforce_hrd),
> > >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > >>
> > >> Does this option work?  I don't seem to be able to push it into
> > >> generating HRD information with any combination of options.
> > >>
> > >
> > > Fixed.
> >
> > What combination of options are needed to get the HRD parameters in
> > the output stream?  I still don't see them with the new version.
> 
> From codec team: AMF HRD parameter ensures that the output stream is
> conformant to HRD bit rate requirements but does not add SEI any other
> stream parameters.
> 
> >
> > >>> +{ "filler_data","Filler Data Enable",   
> > >>> OFFSET(filler_data),
> > >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 14, 2017 9:14 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On 13/11/17 23:00, Mironov, Mikhail wrote:
> >>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, 
> >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 (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) {
> >>
> >> This test is inverted.
> >>
> >> Have you actually tested this path?  Even with that test fixed, I'm
> >> unable to pass the following initialisation test with an AMD D3D11 device.
> >>
> >
> > Yes, the condition should be reverted. To test I had to add "-hwaccel
> > d3d11va -hwaccel_output_format d3d11" to the command line.
> 
> Yeah.  I get:
> 
> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v h264_amf
> out.mp4 ...
> [AVHWDeviceContext @ 0270e120] Created on device 1002:665f
> (AMD Radeon (TM) R7 360 Series).
> ...
> [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx has
> non-AMD device, switching to default
> 
> It's then comedically slow in this state (about 2fps), but works fine when the
> decode is in software.

Is it possible that you also have iGPU not disabled and it is used for decoding 
as adapter 0?
Can you provide a log from dxdiag.exe?
If AMF created own DX device then submission logic an speed is the same as from 
SW decoder. 
It would be interesting to see a short GPUVIEW log.

> 
> >>> +
> >>> +// Dynamic
> >>> +/// Rate Control Method
> >>> +{ "rc", "Rate Control Method",
> >> OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> >> R}, AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> >> _VBR, VE, "rc" },
> >>> +{ "cqp","Constant Quantization Parameter",  0,
> >> AV_OPT_TYPE_CONST, { .i64 =
> >> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP
> },
> >> 0, 0, VE, "rc" },
> >>> +{ "cbr","Constant Bitrate", 0,
> >> AV_OPT_TYPE_CONST, { .i64 =
> >> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0, 0,
> >> VE, "rc" },
> >>> +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
> >> AV_OPT_TYPE_CONST, { .i64 =
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> >> R}, 0, 0, VE, "rc" },
> >>> +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
> >> AV_OPT_TYPE_CONST, { .i64 =
> >>
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> >> _VBR }, 0, 0, VE, "rc" },
> >>
> >> I think the default for this option needs to be decided dynamically.
> >> Just setting "-b:v" is a not-unreasonable thing to do, and currently
> >> the choice of PEAK_CONSTRAINED_VBR makes it then complain that
> maxrate isn't set.
> >> Similarly, if the only setting is some constant-quality option (-q/-
> >> global_quality, or your private ones below), it ignores that and use
> >> the default 2Mbps instead.
> >>
> >>> +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
> >>> +{ "enforce_hrd","Enforce HRD",
> OFFSET(enforce_hrd),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>
> >> Does this option work?  I don't seem to be able to push it into
> >> generating HRD information with any combination of options.
> >>
> >
> > Fixed.
> 
> What combination of options are needed to get the HRD parameters in the
> output stream?  I still don't see them with the new version.

From codec team: AMF HRD parameter ensures that the output stream is conformant 
to HRD bit rate requirements but does not add SEI any other stream parameters. 

> 
> >>> +{ "filler_data","Filler Data Enable",   
> >>> OFFSET(filler_data),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "vbaq",   "Enable VBAQ",  
> >>> OFFSET(enable_vbaq),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "frame_skipping", "Rate Control Based Frame Skip",
> >> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +
> >>> +/// QP Values
> >>> +{ "qp_i",   "Quantization Parameter for I-Frame",   
> >>> OFFSET(qp_i),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +{ "qp_p",   "Quantization Parameter for P-Frame",
> OFFSET(qp_p),
> >> AV_OPT_TYPE_INT, { .i64 = 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 13/11/17 23:00, Mironov, Mikhail wrote:
>>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, >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 (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) {
>>
>> This test is inverted.
>>
>> Have you actually tested this path?  Even with that test fixed, I'm unable to
>> pass the following initialisation test with an AMD D3D11 device.
>>
> 
> Yes, the condition should be reverted. To test I had to add 
> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command line.

Yeah.  I get:

$ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -hwaccel_output_format d3d11 
-i ~/bbb_1080_264.mp4 -an -c:v h264_amf out.mp4
...
[AVHWDeviceContext @ 0270e120] Created on device 1002:665f (AMD Radeon 
(TM) R7 360 Series).
...
[h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx has non-AMD 
device, switching to default

It's then comedically slow in this state (about 2fps), but works fine when the 
decode is in software.

>>> +
>>> +// Dynamic
>>> +/// Rate Control Method
>>> +{ "rc", "Rate Control Method",
>> OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
>> R}, AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
>> _VBR, VE, "rc" },
>>> +{ "cqp","Constant Quantization Parameter",  0,
>> AV_OPT_TYPE_CONST, { .i64 =
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP },
>> 0, 0, VE, "rc" },
>>> +{ "cbr","Constant Bitrate", 0,
>> AV_OPT_TYPE_CONST, { .i64 =
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0, 0,
>> VE, "rc" },
>>> +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
>> AV_OPT_TYPE_CONST, { .i64 =
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
>> R}, 0, 0, VE, "rc" },
>>> +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
>> AV_OPT_TYPE_CONST, { .i64 =
>> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
>> _VBR }, 0, 0, VE, "rc" },
>>
>> I think the default for this option needs to be decided dynamically.  Just
>> setting "-b:v" is a not-unreasonable thing to do, and currently the choice of
>> PEAK_CONSTRAINED_VBR makes it then complain that maxrate isn't set.
>> Similarly, if the only setting is some constant-quality option (-q/-
>> global_quality, or your private ones below), it ignores that and use the
>> default 2Mbps instead.
>>
>>> +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
>>> +{ "enforce_hrd","Enforce HRD",  
>>> OFFSET(enforce_hrd),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>
>> Does this option work?  I don't seem to be able to push it into generating
>> HRD information with any combination of options.
>>
> 
> Fixed.

What combination of options are needed to get the HRD parameters in the output 
stream?  I still don't see them with the new version.

>>> +{ "filler_data","Filler Data Enable",   
>>> OFFSET(filler_data),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +{ "vbaq",   "Enable VBAQ",  
>>> OFFSET(enable_vbaq),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +{ "frame_skipping", "Rate Control Based Frame Skip",
>> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
>>> +
>>> +/// QP Values
>>> +{ "qp_i",   "Quantization Parameter for I-Frame",   
>>> OFFSET(qp_i),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +{ "qp_p",   "Quantization Parameter for P-Frame",   
>>> OFFSET(qp_p),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +{ "qp_b",   "Quantization Parameter for B-Frame",   
>>> OFFSET(qp_b),
>> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
>>> +
>>> +/// Pre-Pass, Pre-Analysis, Two-Pass
>>> +{ "preanalysis","Pre-Analysis Mode",
>>> OFFSET(preanalysis),
>> AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
>>> +
>>> +/// Maximum Access Unit Size
>>> +{ "max_au_size","Maximum Access Unit Size for rate control (in 
>>> bits)",
>> OFFSET(max_au_size),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
>>
>> Can you explain more about what this option does?  I don't seem to be able
>> to get it to do anything - e.g. setting -max_au_size 8 with 30fps CBR 1M
>> (which should be easily achievable) still makes packets of more than 8
>> bits.)
>>
> 
> It means maximum frame size in bits, and it should be 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Mon, Nov 13, 2017 at 06:09:39PM -0500, mmironov wrote:
> From d6f467ec7f610f21f929f9c21f03af3cabe84cf2 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Tue, 7 Nov 2017 10:57:21 -0500
> Subject: [PATCH] Added HW accelerated H.264 and HEVC encoding for AMD
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|1 +
>  compat/amd/amfsdkenc.h   | 1755 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  590 
>  libavcodec/amfenc.h  |  143 
>  libavcodec/amfenc_h264.c |  397 +++
>  libavcodec/amfenc_hevc.c |  328 +
>  9 files changed, 3245 insertions(+)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c

doesnt apply cleanly:
Applying: Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK
.git/rebase-apply/patch:36: trailing whitespace.
//
.git/rebase-apply/patch:37: trailing whitespace.
// MIT license
.git/rebase-apply/patch:38: trailing whitespace.
//
.git/rebase-apply/patch:62: trailing whitespace.
// Full version of AMF SDK and the latest version of this file
.git/rebase-apply/patch:163: trailing whitespace.
#define AMF_WEAK __declspec( selectany )
warning: squelched 46 whitespace errors
warning: 51 lines add whitespace errors.
Using index info to reconstruct a base tree...
M   Changelog
M   configure
M   libavcodec/Makefile
M   libavcodec/allcodecs.c
.git/rebase-apply/patch:36: trailing whitespace.
//
.git/rebase-apply/patch:37: trailing whitespace.
// MIT license
.git/rebase-apply/patch:38: trailing whitespace.
//
.git/rebase-apply/patch:62: trailing whitespace.
// Full version of AMF SDK and the latest version of this file
.git/rebase-apply/patch:163: trailing whitespace.
#define AMF_WEAK __declspec( selectany )
warning: squelched 46 whitespace errors
warning: 51 lines applied after fixing whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging libavcodec/allcodecs.c
Auto-merging libavcodec/Makefile
CONFLICT (content): Merge conflict in libavcodec/Makefile
Auto-merging configure
CONFLICT (content): Merge conflict in configure
Auto-merging Changelog
CONFLICT (content): Merge conflict in Changelog
error: Failed to merge in the changes.
Patch failed at 0001 Added HW H.264 and HEVC encoding for AMD GPUs based on AMF 
SDK
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> > +res = ctx->factory->pVtbl->CreateContext(ctx->factory, >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 (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) {
> 
> This test is inverted.
> 
> Have you actually tested this path?  Even with that test fixed, I'm unable to
> pass the following initialisation test with an AMD D3D11 device.
> 

Yes, the condition should be reverted. To test I had to add 
"-hwaccel d3d11va -hwaccel_output_format d3d11" to the command line.

> > +
> > +// Dynamic
> > +/// Rate Control Method
> > +{ "rc", "Rate Control Method",
> OFFSET(rate_control_mode),  AV_OPT_TYPE_INT,   { .i64 =
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> R}, AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP,
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> _VBR, VE, "rc" },
> > +{ "cqp","Constant Quantization Parameter",  0,
> AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CONSTANT_QP },
> 0, 0, VE, "rc" },
> > +{ "cbr","Constant Bitrate", 0,
> AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_CBR }, 0, 0,
> VE, "rc" },
> > +{ "vbr_peak",   "Peak Contrained Variable Bitrate", 0,
> AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_PEAK_CONSTRAINED_VB
> R}, 0, 0, VE, "rc" },
> > +{ "vbr_latency","Latency Constrained Variable Bitrate", 0,
> AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_RATE_CONTROL_METHOD_LATENCY_CONSTRAINED
> _VBR }, 0, 0, VE, "rc" },
> 
> I think the default for this option needs to be decided dynamically.  Just
> setting "-b:v" is a not-unreasonable thing to do, and currently the choice of
> PEAK_CONSTRAINED_VBR makes it then complain that maxrate isn't set.
> Similarly, if the only setting is some constant-quality option (-q/-
> global_quality, or your private ones below), it ignores that and use the
> default 2Mbps instead.
> 
> > +/// Enforce HRD, Filler Data, VBAQ, Frame Skipping
> > +{ "enforce_hrd","Enforce HRD",  
> > OFFSET(enforce_hrd),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> 
> Does this option work?  I don't seem to be able to push it into generating
> HRD information with any combination of options.
> 

Fixed.

> > +{ "filler_data","Filler Data Enable",   
> > OFFSET(filler_data),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "vbaq",   "Enable VBAQ",  
> > OFFSET(enable_vbaq),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "frame_skipping", "Rate Control Based Frame Skip",
> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +
> > +/// QP Values
> > +{ "qp_i",   "Quantization Parameter for I-Frame",   
> > OFFSET(qp_i),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> > +{ "qp_p",   "Quantization Parameter for P-Frame",   
> > OFFSET(qp_p),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> > +{ "qp_b",   "Quantization Parameter for B-Frame",   
> > OFFSET(qp_b),
> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> > +
> > +/// Pre-Pass, Pre-Analysis, Two-Pass
> > +{ "preanalysis","Pre-Analysis Mode",
> > OFFSET(preanalysis),
> AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
> > +
> > +/// Maximum Access Unit Size
> > +{ "max_au_size","Maximum Access Unit Size for rate control (in 
> > bits)",
> OFFSET(max_au_size),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
> 
> Can you explain more about what this option does?  I don't seem to be able
> to get it to do anything - e.g. setting -max_au_size 8 with 30fps CBR 1M
> (which should be easily achievable) still makes packets of more than 8
> bits.)
> 

It means maximum frame size in bits, and it should be used together 
with enforce_hrd enabled.  I tested, it works after the related fix for 
enforce_hrd.
I added  dependency handling.

> 
> And some thoughts on the stream it makes:
> 
> "ffmpeg_g -report -y -f lavfi -i testsrc -an -c:v h264_amf -bsf:v 
> trace_headers -
> frames:v 1000 out.mp4"
> 
> [AVBSFContext @ 0049b9c0] Sequence Parameter Set
> [AVBSFContext @ 0049b9c0] 40  max_num_ref_frames
> 00101 = 4
> [AVBSFContext @ 0049b9c0] 206 max_dec_frame_buffering
> 00101 = 4
> 
> Where did 4 come from?  It never uses more than 1 reference in the stream.

According to codec guys this field filled in by HW and represents how many 
frames can be stored in 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 05/11/17 03:49, Mikhail Mironov wrote:
> From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1753 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  515 ++
>  libavcodec/amfenc.h  |  137 
>  libavcodec/amfenc_h264.c |  366 ++
>  libavcodec/amfenc_hevc.c |  294 
>  libavcodec/version.h |4 +-
>  10 files changed, 3100 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> ...
> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> new file mode 100644
> index 000..fcfbd20
> --- /dev/null
> +++ b/libavcodec/amfenc.c
> ...
> +
> +static int amf_init_context(AVCodecContext *avctx)
> +{
> +AmfContext *ctx = avctx->priv_data;
> +AMF_RESULT  res = AMF_OK;
> +
> +// confugure AMF logger
> +// the return of these functions indicates old state and do not affect 
> behaviour
> +ctx->trace->pVtbl->EnableWriter(ctx->trace, 
> AMF_TRACE_WRITER_DEBUG_OUTPUT, ctx->log_to_dbg != 0 );
> +if (ctx->log_to_dbg)
> +ctx->trace->pVtbl->SetWriterLevel(ctx->trace, 
> AMF_TRACE_WRITER_DEBUG_OUTPUT, AMF_TRACE_TRACE);
> +ctx->trace->pVtbl->EnableWriter(ctx->trace, AMF_TRACE_WRITER_CONSOLE, 0);
> +ctx->trace->pVtbl->SetGlobalLevel(ctx->trace, AMF_TRACE_TRACE);
> +
> +// connect AMF logger to av_log
> +ctx->tracer.vtbl = _vtbl;
> +ctx->tracer.avctx = avctx;
> +ctx->trace->pVtbl->RegisterWriter(ctx->trace, 
> FFMPEG_AMF_WRITER_ID,(AMFTraceWriter*)>tracer, 1);
> +ctx->trace->pVtbl->SetWriterLevel(ctx->trace, FFMPEG_AMF_WRITER_ID, 
> AMF_TRACE_TRACE);
> +
> +res = ctx->factory->pVtbl->CreateContext(ctx->factory, >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 (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) {

This test is inverted.

Have you actually tested this path?  Even with that test fixed, I'm unable to 
pass the following initialisation test with an AMD D3D11 device.

> +if (device_ctx->device_ctx->hwctx) {
> +AVD3D11VADeviceContext *device_d3d11 = 
> (AVD3D11VADeviceContext *)device_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);
> +}else {
> +av_log(avctx, AV_LOG_INFO, "amf_shared: 
> avctx->hw_frames_ctx has non-AMD device, switching to default\n");
> +}
> +}
> +}else {
> +av_log(avctx, AV_LOG_INFO, "amf_shared: avctx->hw_frames_ctx 
> has format not uspported by AMF, switching to default\n");
> +}
> +}
> +} else if (avctx->hw_device_ctx) {
> +AVHWDeviceContext *device_ctx = 
> (AVHWDeviceContext*)(avctx->hw_device_ctx->data);
> +if (device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
> +if (device_ctx->hwctx) {
> +AVD3D11VADeviceContext *device_d3d11 = 
> (AVD3D11VADeviceContext *)device_ctx->hwctx;
> +res = ctx->context->pVtbl->InitDX11(ctx->context, 
> device_d3d11->device, AMF_DX11_1);
> +if (res == AMF_OK) {
> +ctx->hw_device_ctx = av_buffer_ref(avctx->hw_device_ctx);
> +} else {
> +av_log(avctx, AV_LOG_INFO, "amf_shared: 
> avctx->hw_device_ctx has non-AMD device, switching to default\n");
> +}
> +}
> +}
> +}
> +if (!ctx->hw_frames_ctx && !ctx->hw_device_ctx) {
> +res = ctx->context->pVtbl->InitDX11(ctx->context, NULL, AMF_DX11_1);
> +if (res != AMF_OK) {
> +res = ctx->context->pVtbl->InitDX9(ctx->context, NULL);
> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, 
> "InitDX9() failed with error %d\n", res);
> +}
> +}
> +return 0;
> +}
> +
> +static int 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 8, 2017 10:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On 06/11/17 22:46, Michael Niedermayer wrote:
> > ...
> > In file included from src/libavcodec/amfenc.h:24:0,
> >  from src/libavcodec/amfenc.c:27:
> > src/compat/amd/amfsdkenc.h:191:23: error: no previous prototype for
> > ‘AMFConstructRect’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFRect AMFConstructRect(amf_int32 left, amf_int32 top, amf_int32 right,
> amf_int32 bottom)
> >^
> > src/compat/amd/amfsdkenc.h:203:23: error: no previous prototype for
> > ‘AMFConstructSize’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFSize AMFConstructSize(amf_int32 width, amf_int32 height)
> >^
> > src/compat/amd/amfsdkenc.h:215:24: error: no previous prototype for
> > ‘AMFConstructPoint’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFPoint AMFConstructPoint(amf_int32 x, amf_int32 y)
> > ^
> > src/compat/amd/amfsdkenc.h:227:23: error: no previous prototype for
> > ‘AMFConstructRate’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFRate AMFConstructRate(amf_uint32 num, amf_uint32 den)
> >^
> > src/compat/amd/amfsdkenc.h:239:24: error: no previous prototype for
> > ‘AMFConstructRatio’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFRatio AMFConstructRatio(amf_uint32 num, amf_uint32 den)
> > ^
> > In file included from src/libavcodec/amfenc.h:24:0,
> >  from src/libavcodec/amfenc.c:27:
> > src/compat/amd/amfsdkenc.h:275:24: error: no previous prototype for
> > ‘AMFConstructColor’ [-Werror=missing-prototypes]  AMF_INLINE struct
> AMFColor AMFConstructColor(amf_uint8 r, amf_uint8 g, amf_uint8 b,
> amf_uint8 a)
> > ^
> > In file included from src/libavcodec/amfenc.h:24:0,
> >  from src/libavcodec/amfenc.c:27:
> > src/compat/amd/amfsdkenc.h:293:45: error: no previous prototype for
> ‘amf_variant_alloc’ [-Werror=missing-prototypes]
> >  AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
> >  ^
> > src/compat/amd/amfsdkenc.h:297:44: error: no previous prototype for
> ‘amf_variant_free’ [-Werror=missing-prototypes]
> >  AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
> > ^
> > cc1: some warnings being treated as errors
> > make: *** [libavcodec/amfenc.o] Error 1
> 
> This is showing an error in the AMF C API.
> 
> AMF_INLINE is defined at  LibrariesAndSDKs/AMF/blob/master/amf/public/include/core/Platform.h#L9
> 9> as just "__inline__" (i.e. "inline"), so these functions are all inline 
> without
> a storage class specifier.  But, no external definition actually exists 
> anywhere,
> so if the compiler doesn't inline all instances you will fail to link.
> 
> (The behaviour is not the same in C++, where external versions are
> generated anyway in this case and then the multiple instances collapsed
> together later by invoking the ODR.)
> 
> Trivial test case (gcc defaults to not inlining anything when no optimisation
> options are given):
> 
> $ cat amf-inline.c
> #include "Platform.h"
> 
> int main(void)
> {
> AMFSize size;
> size = AMFConstructSize(123, 456);
> return 0;
> }
> $ gcc -std=c99 amf-inline.c
> In file included from amf-inline.c:1:0:
> Platform.h: In function ‘AMFCompareGUIDs’:
> Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ [-
> Wimplicit-function-declaration]
>  return memcmp(, , sizeof(guid1)) == 0;
> ^
> /tmp/ccMCUBTW.o: In function `main':
> amf-inline.c:(.text+0x13): undefined reference to `AMFConstructSize'
> collect2: error: ld returned 1 exit status $ gcc -c -std=c99 amf-inline.c In 
> file
> included from amf-inline.c:1:0:
> Platform.h: In function ‘AMFCompareGUIDs’:
> Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ [-
> Wimplicit-function-declaration]
>  return memcmp(, , sizeof(guid1)) == 0;
> ^
> $ nm amf-inline.o
>  U AMFConstructSize
>  T main
> $ gcc -O1 -std=c99 amf-inline.c
> In file included from amf-inline.c:1:0:
> Platform.h: In function ‘AMFCompareGUIDs’:
> Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ [-
> Wimplicit-function-declaration]
>  return memcmp(, , sizeof(guid1)) == 0;
> ^
> $
> 
> I think AMF_INLINE should for these functions instead be "static inline"
> (though I didn't look at all uses, so there may be others where this isn't 
> true).


Yes, this is the issue. I found that in most of the functions "static" was 
added 
but not to these few. And my debug 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 06/11/17 22:46, Michael Niedermayer wrote:
> ...
> In file included from src/libavcodec/amfenc.h:24:0,
>  from src/libavcodec/amfenc.c:27:
> src/compat/amd/amfsdkenc.h:191:23: error: no previous prototype for 
> ‘AMFConstructRect’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFRect AMFConstructRect(amf_int32 left, amf_int32 top, 
> amf_int32 right, amf_int32 bottom)
>^
> src/compat/amd/amfsdkenc.h:203:23: error: no previous prototype for 
> ‘AMFConstructSize’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFSize AMFConstructSize(amf_int32 width, amf_int32 height)
>^
> src/compat/amd/amfsdkenc.h:215:24: error: no previous prototype for 
> ‘AMFConstructPoint’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFPoint AMFConstructPoint(amf_int32 x, amf_int32 y)
> ^
> src/compat/amd/amfsdkenc.h:227:23: error: no previous prototype for 
> ‘AMFConstructRate’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFRate AMFConstructRate(amf_uint32 num, amf_uint32 den)
>^
> src/compat/amd/amfsdkenc.h:239:24: error: no previous prototype for 
> ‘AMFConstructRatio’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFRatio AMFConstructRatio(amf_uint32 num, amf_uint32 den)
> ^
> In file included from src/libavcodec/amfenc.h:24:0,
>  from src/libavcodec/amfenc.c:27:
> src/compat/amd/amfsdkenc.h:275:24: error: no previous prototype for 
> ‘AMFConstructColor’ [-Werror=missing-prototypes]
>  AMF_INLINE struct AMFColor AMFConstructColor(amf_uint8 r, amf_uint8 g, 
> amf_uint8 b, amf_uint8 a)
> ^
> In file included from src/libavcodec/amfenc.h:24:0,
>  from src/libavcodec/amfenc.c:27:
> src/compat/amd/amfsdkenc.h:293:45: error: no previous prototype for 
> ‘amf_variant_alloc’ [-Werror=missing-prototypes]
>  AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
>  ^
> src/compat/amd/amfsdkenc.h:297:44: error: no previous prototype for 
> ‘amf_variant_free’ [-Werror=missing-prototypes]
>  AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
> ^
> cc1: some warnings being treated as errors
> make: *** [libavcodec/amfenc.o] Error 1

This is showing an error in the AMF C API.

AMF_INLINE is defined at 

 as just "__inline__" (i.e. "inline"), so these functions are all inline 
without a storage class specifier.  But, no external definition actually exists 
anywhere, so if the compiler doesn't inline all instances you will fail to link.

(The behaviour is not the same in C++, where external versions are generated 
anyway in this case and then the multiple instances collapsed together later by 
invoking the ODR.)

Trivial test case (gcc defaults to not inlining anything when no optimisation 
options are given):

$ cat amf-inline.c
#include "Platform.h"

int main(void)
{
AMFSize size;
size = AMFConstructSize(123, 456);
return 0;
}
$ gcc -std=c99 amf-inline.c
In file included from amf-inline.c:1:0:
Platform.h: In function ‘AMFCompareGUIDs’:
Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ 
[-Wimplicit-function-declaration]
 return memcmp(, , sizeof(guid1)) == 0;
^
/tmp/ccMCUBTW.o: In function `main':
amf-inline.c:(.text+0x13): undefined reference to `AMFConstructSize'
collect2: error: ld returned 1 exit status
$ gcc -c -std=c99 amf-inline.c
In file included from amf-inline.c:1:0:
Platform.h: In function ‘AMFCompareGUIDs’:
Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ 
[-Wimplicit-function-declaration]
 return memcmp(, , sizeof(guid1)) == 0;
^
$ nm amf-inline.o 
 U AMFConstructSize
 T main
$ gcc -O1 -std=c99 amf-inline.c
In file included from amf-inline.c:1:0:
Platform.h: In function ‘AMFCompareGUIDs’:
Platform.h:421:16: warning: implicit declaration of function ‘memcmp’ 
[-Wimplicit-function-declaration]
 return memcmp(, , sizeof(guid1)) == 0;
^
$ 

I think AMF_INLINE should for these functions instead be "static inline" 
(though I didn't look at all uses, so there may be others where this isn't 
true).

- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: November 7, 2017 3:25 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Tue, Nov 7, 2017 at 12:28 AM, Mironov, Mikhail
>  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Michael Niedermayer
> >> Sent: November 6, 2017 5:47 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for
> AMD
> >> GPUs based on AMF SDK
> >>
> >> On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> >> > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17
> 00:00:00
> >> 2001
> >> > From: mmironov 
> >> > Date: Fri, 27 Oct 2017 13:03:15 -0400
> >> > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
> >> AMD
> >> > GPUs  based on AMF SDK
> >> >
> >> > Signed-off-by: mmironov 
> >> > ---
> >> >  Changelog|3 +-
> >> >  compat/amd/amfsdkenc.h   | 1753
> >> ++
> >> >  configure|   25 +
> >> >  libavcodec/Makefile  |4 +
> >> >  libavcodec/allcodecs.c   |2 +
> >> >  libavcodec/amfenc.c  |  515 ++
> >> >  libavcodec/amfenc.h  |  137 
> >> >  libavcodec/amfenc_h264.c |  366 ++
> >> > libavcodec/amfenc_hevc.c
> >> > |  294 
> >> >  libavcodec/version.h |4 +-
> >> >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
> >> > 100644 compat/amd/amfsdkenc.h  create mode 100644
> >> libavcodec/amfenc.c
> >> > create mode 100644 libavcodec/amfenc.h  create mode 100644
> >> > libavcodec/amfenc_h264.c  create mode 100644
> >> > libavcodec/amfenc_hevc.c
> >>
> >> This seems to fail building in mingw64
> >
> > This is strange. Just in case: my build setup is described here:
> > https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
> >
> > I also attached full amfsdkenc.h header file in case I made a mistake with
> git integration.
> >
> >
> >>
> >> make
> >> CC  libavcodec/amfenc.o
> >> In file included from src/libavcodec/amfenc.c:22:0:
> >> src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
> >> ‘ID3D11VideoDevice’
> >>  ID3D11VideoDevice   *video_device;
> >>  ^
> >> src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
> >> ‘ID3D11VideoContext’
> >>  ID3D11VideoContext  *video_context;
> >>  ^
> >
> > This is declared in d3d11.h and came with mingw64. Mine version has it:
> > msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> > Is it possible that we use different versions of mingw? Do you have it
> declared?
> >
> 
> If you use/rely on hwcontext_d3d11va, you should probably have a
> configure dependency on that part being available.

OK, use of hwcontext_d3d11va  is optional, I will put the dependent parts of 
the code under #ifdef

> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Hendrik Leppkes]

On Tue, Nov 7, 2017 at 12:28 AM, Mironov, Mikhail
 wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Michael Niedermayer
>> Sent: November 6, 2017 5:47 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
>> GPUs based on AMF SDK
>>
>> On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
>> > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00
>> 2001
>> > From: mmironov 
>> > Date: Fri, 27 Oct 2017 13:03:15 -0400
>> > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
>> AMD
>> > GPUs  based on AMF SDK
>> >
>> > Signed-off-by: mmironov 
>> > ---
>> >  Changelog|3 +-
>> >  compat/amd/amfsdkenc.h   | 1753
>> ++
>> >  configure|   25 +
>> >  libavcodec/Makefile  |4 +
>> >  libavcodec/allcodecs.c   |2 +
>> >  libavcodec/amfenc.c  |  515 ++
>> >  libavcodec/amfenc.h  |  137 
>> >  libavcodec/amfenc_h264.c |  366 ++  libavcodec/amfenc_hevc.c
>> > |  294 
>> >  libavcodec/version.h |4 +-
>> >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
>> > 100644 compat/amd/amfsdkenc.h  create mode 100644
>> libavcodec/amfenc.c
>> > create mode 100644 libavcodec/amfenc.h  create mode 100644
>> > libavcodec/amfenc_h264.c  create mode 100644 libavcodec/amfenc_hevc.c
>>
>> This seems to fail building in mingw64
>
> This is strange. Just in case: my build setup is described here:
> https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
>
> I also attached full amfsdkenc.h header file in case I made a mistake with 
> git integration.
>
>
>>
>> make
>> CC  libavcodec/amfenc.o
>> In file included from src/libavcodec/amfenc.c:22:0:
>> src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
>> ‘ID3D11VideoDevice’
>>  ID3D11VideoDevice   *video_device;
>>  ^
>> src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
>> ‘ID3D11VideoContext’
>>  ID3D11VideoContext  *video_context;
>>  ^
>
> This is declared in d3d11.h and came with mingw64. Mine version has it:
> msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> Is it possible that we use different versions of mingw? Do you have it 
> declared?
>

If you use/rely on hwcontext_d3d11va, you should probably have a
configure dependency on that part being available.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Tue, Nov 07, 2017 at 01:36:57AM +, Mironov, Mikhail wrote:
> 
> 
> > theres no match for ID3D11VideoContext in my d3d11.h
> 
> > my mingw stuff should be just the official packages from
> > ubuntu LTS 14.04
> 
> Then how would you compile hwcontext_d3d11va.h where ID3D11DeviceContext and 
> ID3D11VideoDevice  are used?

config.h lists:
#define CONFIG_D3D11VA 0

so this would not get compiled as its disabled


> 
> Thanks,
> Mikhail
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> theres no match for ID3D11VideoContext in my d3d11.h

> my mingw stuff should be just the official packages from
> ubuntu LTS 14.04

Then how would you compile hwcontext_d3d11va.h where ID3D11DeviceContext and 
ID3D11VideoDevice  are used?

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Mon, Nov 06, 2017 at 11:28:38PM +, Mironov, Mikhail wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Michael Niedermayer
> > Sent: November 6, 2017 5:47 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> > GPUs based on AMF SDK
> > 
> > On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> > > From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00
> > 2001
> > > From: mmironov 
> > > Date: Fri, 27 Oct 2017 13:03:15 -0400
> > > Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for
> > AMD
> > > GPUs  based on AMF SDK
> > >
> > > Signed-off-by: mmironov 
> > > ---
> > >  Changelog|3 +-
> > >  compat/amd/amfsdkenc.h   | 1753
> > ++
> > >  configure|   25 +
> > >  libavcodec/Makefile  |4 +
> > >  libavcodec/allcodecs.c   |2 +
> > >  libavcodec/amfenc.c  |  515 ++
> > >  libavcodec/amfenc.h  |  137 
> > >  libavcodec/amfenc_h264.c |  366 ++  libavcodec/amfenc_hevc.c
> > > |  294 
> > >  libavcodec/version.h |4 +-
> > >  10 files changed, 3100 insertions(+), 3 deletions(-)  create mode
> > > 100644 compat/amd/amfsdkenc.h  create mode 100644
> > libavcodec/amfenc.c
> > > create mode 100644 libavcodec/amfenc.h  create mode 100644
> > > libavcodec/amfenc_h264.c  create mode 100644 libavcodec/amfenc_hevc.c
> > 
> > This seems to fail building in mingw64
> 
> This is strange. Just in case: my build setup is described here:
> https://github.com/Xaymar/ffmpeg-amf/blob/master/Build.txt
> 
> I also attached full amfsdkenc.h header file in case I made a mistake with 
> git integration.
> 
> 
> > 
> > make
> > CC  libavcodec/amfenc.o
> > In file included from src/libavcodec/amfenc.c:22:0:
> > src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name
> > ‘ID3D11VideoDevice’
> >  ID3D11VideoDevice   *video_device;
> >  ^
> > src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name
> > ‘ID3D11VideoContext’
> >  ID3D11VideoContext  *video_context;
> >  ^
> 
> This is declared in d3d11.h and came with mingw64. Mine version has it:
> msys64new\mingw64\x86_64-w64-mingw32\include\d3d11.h  - attached.
> Is it possible that we use different versions of mingw? Do you have it 
> declared?

theres no match for ID3D11VideoContext in my d3d11.h

my mingw stuff should be just the official packages from
ubuntu LTS 14.04

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 10:49:44PM -0500, Mikhail Mironov wrote:
> From fc6a3f63eb9c3734f4101cee2a2f5707e063ab62 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1753 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  515 ++
>  libavcodec/amfenc.h  |  137 
>  libavcodec/amfenc_h264.c |  366 ++
>  libavcodec/amfenc_hevc.c |  294 
>  libavcodec/version.h |4 +-
>  10 files changed, 3100 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c

This seems to fail building in mingw64

make
CC  libavcodec/amfenc.o
In file included from src/libavcodec/amfenc.c:22:0:
src/libavutil/hwcontext_d3d11va.h:71:5: error: unknown type name 
‘ID3D11VideoDevice’
 ID3D11VideoDevice   *video_device;
 ^
src/libavutil/hwcontext_d3d11va.h:79:5: error: unknown type name 
‘ID3D11VideoContext’
 ID3D11VideoContext  *video_context;
 ^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:191:23: error: no previous prototype for 
‘AMFConstructRect’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRect AMFConstructRect(amf_int32 left, amf_int32 top, 
amf_int32 right, amf_int32 bottom)
   ^
src/compat/amd/amfsdkenc.h:203:23: error: no previous prototype for 
‘AMFConstructSize’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFSize AMFConstructSize(amf_int32 width, amf_int32 height)
   ^
src/compat/amd/amfsdkenc.h:215:24: error: no previous prototype for 
‘AMFConstructPoint’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFPoint AMFConstructPoint(amf_int32 x, amf_int32 y)
^
src/compat/amd/amfsdkenc.h:227:23: error: no previous prototype for 
‘AMFConstructRate’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRate AMFConstructRate(amf_uint32 num, amf_uint32 den)
   ^
src/compat/amd/amfsdkenc.h:239:24: error: no previous prototype for 
‘AMFConstructRatio’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFRatio AMFConstructRatio(amf_uint32 num, amf_uint32 den)
^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:275:24: error: no previous prototype for 
‘AMFConstructColor’ [-Werror=missing-prototypes]
 AMF_INLINE struct AMFColor AMFConstructColor(amf_uint8 r, amf_uint8 g, 
amf_uint8 b, amf_uint8 a)
^
In file included from src/libavcodec/amfenc.h:24:0,
 from src/libavcodec/amfenc.c:27:
src/compat/amd/amfsdkenc.h:293:45: error: no previous prototype for 
‘amf_variant_alloc’ [-Werror=missing-prototypes]
 AMF_INLINE void* AMF_CDECL_CALL amf_variant_alloc(amf_size count)
 ^
src/compat/amd/amfsdkenc.h:297:44: error: no previous prototype for 
‘amf_variant_free’ [-Werror=missing-prototypes]
 AMF_INLINE void AMF_CDECL_CALL amf_variant_free(void* ptr)
^
cc1: some warnings being treated as errors
make: *** [libavcodec/amfenc.o] Error 1


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: November 5, 2017 2:11 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Sun, Nov 05, 2017 at 02:41:54 +, Mironov, Mikhail wrote:
> 
> > > > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> > > AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY  }, 0, 0, VE,
> > > "quality" },
> > >
> > > These are 0, 5, 10.  Do the intermediate values work?  Should they
> > > be exposed?
> > >
> > Only enum values are supported. I guess they left space for future
> extensions.
> 
> What if an unsupported value is passed via
> AMF_ASSIGN_PROPERTY_INT64()?
> Despite enumerated values, ffmpeg allows to pass numerical values, and you
> don't verify that they are only 0, 5, 10.

AMF runtime has strict verification. Error will be returned. 

> 
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Moritz Barsnick]

On Sun, Nov 05, 2017 at 02:41:54 +, Mironov, Mikhail wrote:

> > > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> > AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY  }, 0, 0, VE,
> > "quality" },
> > 
> > These are 0, 5, 10.  Do the intermediate values work?  Should they be
> > exposed?
> > 
> Only enum values are supported. I guess they left space for future 
> extensions. 

What if an unsupported value is passed via AMF_ASSIGN_PROPERTY_INT64()?
Despite enumerated values, ffmpeg allows to pass numerical values, and
you don't verify that they are only 0, 5, 10.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> > +//
> > +
> > +// Reduced AMF API
> > +//
> > +// Full version of AMF SDK and the latest version of this file
> > +// can be found at https://github.com/GPUOpen-LibrariesAndSDKs/AMF
> 
> On further consideration I am against including this header.  Just ask the 
> user
> to get it from this link you are including anyway.  (Also maybe make that
> packagable by providing some means to install it, preferably including pkg-
> config support.)
> 

You put very accurate description of the situation in a different thread. 
Few opinions were expressed but then discussion paused.
How does this group resolve such issues?


> > +
> > +#define PTS_PROP L"PtsProp"
> 
> Who is defining this key?  (Does the AMF code look inside it?)
> 

This key is the private one for amfenc implementation in ffmpeg. AMF runtime 
will pass it 
though to the output object.

> > +
> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> > +AV_PIX_FMT_NV12,
> > +AV_PIX_FMT_RGB0,
> > +AV_PIX_FMT_BGR0,
> 
> I still think including RGB formats here is a bad idea without any colourspace
> support.

There are pros and cons here.:
Pros: it will provide HW acceleration in simple cases. 
Cons: no control for user.
I will remove it till I expose color converter property from the encoder in 
runtime implementation. 
Currently supported are 601, 709 and JPEG. Is it good enough to reinstate these 
formats once such 
encoder option is added?

> > +buffer->pVtbl->GetProperty(buffer, PTS_PROP, );
> > +
> > +pkt->pts = var.int64Value; // original pts
> > +pkt->dts = buffer->pVtbl->GetPts(buffer); // in monotonic order
> 
> Does the GetPts function really return the DTS?

Yes. Though DTS is not exactly the right term. The component will reorder PTSs 
that are set in SetPts() (in case of B-frames) 
and return them in GetPts() - so it is monotonic order timestamps. BTW: NV has 
the same behavior, only PTS reordering 
is done in ffmpeg code.


> > +res = ctx->context->pVtbl->CreateSurfaceFromDX11Native(ctx-
> >context, texture, , NULL); // wrap to AMF surface
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR(ENOMEM),
> "CreateSurfaceFromDX11Native() failed  with error %d\n", res);
> 
> I think you will need to hold a reference to the input frame while it's in the
> encoder here, assuming it doesn't get copied away immediately.  If not, it 
> will
> be returned to the frame pool and might be reused by someone else - it can't
> be freed because you are holding a reference to its frames context, but I
> think it can be written to.
> 
> (I could believe that testing with ffmpeg (something like "./ffmpeg_g -hwaccel
> d3d11va -hwaccel_output_format d3d11 input.mp4 -c:v h264_amf ...
> output.mp4", presumably?) is not sufficient to show any problems here.  Not
> sure what would be.)

I will add ref to the frame if it is D3D11. In case of system memory it was 
already copied. 

> 
> Just to confirm, the encoder will /always/ be able to consume the new
> surface after returning a packet?

Yes at this point. 

> > +{ "baseline",   "", 0,  
> > AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_PROFILE_BASELINE }, 0, 0, VE, "profile" },
> 
> I still very much doubt you support baseline profile.  Please remove it to
> avoid confusion.

According to codec it is but I will remove - not much use of it. 

> > +{ "quality","", 0, AV_OPT_TYPE_CONST, { .i64 =
> AMF_VIDEO_ENCODER_HEVC_QUALITY_PRESET_QUALITY  }, 0, 0, VE,
> "quality" },
> 
> These are 0, 5, 10.  Do the intermediate values work?  Should they be
> exposed?
> 
Only enum values are supported. I guess they left space for future extensions. 

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 31/10/17 19:39, mmironov wrote:
> From 8640b995634f827eb39ae87bcbe2c1992d8140f2 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1753 
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  513 ++
>  libavcodec/amfenc.h  |  136 
>  libavcodec/amfenc_h264.c |  368 ++
>  libavcodec/amfenc_hevc.c |  296 
>  libavcodec/version.h |4 +-
>  10 files changed, 3101 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> diff --git a/Changelog b/Changelog
> index 6592d86..f0d22fa 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,7 +6,8 @@ version :
>  - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
>requires 2.1 (or later) and pkg-config.
>  - VDA dropped (use VideoToolbox instead)
> -
> +- AMF H.264 encoder
> +- AMF HEVC encoder
>  
>  version 3.4:
>  - deflicker video filter
> diff --git a/compat/amd/amfsdkenc.h b/compat/amd/amfsdkenc.h
> new file mode 100644
> index 000..0d48451
> --- /dev/null
> +++ b/compat/amd/amfsdkenc.h> @@ -0,0 +1,1753 @@
> +// 
> +// MIT license 
> +// 
> +// Copyright (c) 2017 Advanced Micro Devices, Inc. All rights reserved.
> +//
> +// Permission is hereby granted, free of charge, to any person obtaining a 
> copy
> +// of this software and associated documentation files (the "Software"), to 
> deal
> +// in the Software without restriction, including without limitation the 
> rights
> +// to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> +// copies of the Software, and to permit persons to whom the Software is
> +// furnished to do so, subject to the following conditions:
> +//
> +// The above copyright notice and this permission notice shall be included in
> +// all copies or substantial portions of the Software.
> +//
> +// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> +// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> +// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL 
> THE
> +// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> +// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
> FROM,
> +// OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> +// THE SOFTWARE.
> +//
> +
> +// Reduced AMF API
> +//
> +// Full version of AMF SDK and the latest version of this file 
> +// can be found at https://github.com/GPUOpen-LibrariesAndSDKs/AMF

On further consideration I am against including this header.  Just ask the user 
to get it from this link you are including anyway.  (Also maybe make that 
packagable by providing some means to install it, preferably including 
pkg-config support.)

> diff --git a/configure b/configure
> index 0e1ccaa..403e010 100755
> --- a/configure
> +++ b/configure
> @@ -304,6 +304,7 @@ External library support:
>  
>The following libraries provide various hardware acceleration features:
>--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
> +  --disable-amfdisable AMF video encoding code [autodetect]

m < u

>--disable-cuda   disable dynamically linked Nvidia CUDA code 
> [autodetect]
>--enable-cuda-sdkenable CUDA features that require the CUDA SDK 
> [no]
>--disable-cuvid  disable Nvidia CUVID support [autodetect]
> @@ -1641,6 +1642,7 @@ EXTERNAL_LIBRARY_LIST="
>  "
>  
>  HWACCEL_AUTODETECT_LIBRARY_LIST="
> +amf
>  audiotoolbox
>  crystalhd
>  cuda
> @@ -2785,12 +2787,15 @@ scale_npp_filter_deps="cuda libnpp"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>  
> +amf_deps_any="dlopen LoadLibrary"
> +
>  nvenc_deps="cuda"
>  nvenc_deps_any="libdl LoadLibrary"
>  nvenc_encoder_deps="nvenc"
>  
>  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
> +h264_amf_encoder_deps="amf"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
>  h264_cuvid_decoder_deps="cuda cuvid"
>  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
> @@ -2809,6 +2814,7 @@ 
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
>  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
>  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
> +hevc_amf_encoder_deps="amf"
>  

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of mmironov
> Sent: October 31, 2017 3:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs
> based on AMF SDK
> 
> From 8640b995634f827eb39ae87bcbe2c1992d8140f2 Mon Sep 17 00:00:00
> 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD
> GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1753
> ++
>  configure|   25 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  513 ++
>  libavcodec/amfenc.h  |  136 
>  libavcodec/amfenc_h264.c |  368 ++
>  libavcodec/amfenc_hevc.c |  296 
>  libavcodec/version.h |4 +-
>  10 files changed, 3101 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> diff --git a/Changelog b/Changelog
> index 6592d86..f0d22fa 100644
> --- a/Changelog
> +++ b/Changelog

Don’t want to push but is it possible that this submit was skipped?
Thanks, Mikhail 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: October 31, 2017 2:06 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 
> On Tue, 31 Oct 2017, Mironov, Mikhail wrote:
> 
> [...]
> 
> >> I see some confusion. The user can call send_frame/receive_packet in
> >> any order, and you can implement send_frame and receive_packet any
> >> way you want, the only thing you have to guarantee is that you cannot
> >> return EAGAIN for both send_frame and receive_packet. Not even
> temporarily.
> >>
> >> If you returned EAGAIN in send_frame, you must return success or a
> >> normal error in receive_packet. If you returned EAGAIN in
> >> receive_packet, you must return success or a normal error in send_frame.
> >>
> >> By returning EAGAIN in receive_packet you make sure that the API user
> >> submits as many frames as needed to fill your pipeline.
> >>
> >> The simplest solution really seems to me what Mark proposed:
> >>
> >> send_frame:
> >>
> >> if (have_stored_frame)
> >>return EAGAIN;
> >> if (amd_send_frame() == INPUT_FULL)
> >>store_frame;
> >> return 0;
> >>
> >> receive_packet:
> >>
> >> if (have_stored_frame) {
> >>if (amd_send_frame() == OK)
> >>   unstore_frame;
> >>block_until_have_packet
> >>return packet
> >> } else {
> >>return EAGAIN
> >> }
> >>
> >> I hope I did not mess it up, proper draining and error handling
> >> obviously needs some minor changes.
> >>
> >
> > The logic in receive_packet() will be slightly different but I will figure 
> > this
> out.
> > My only note is that returning EAGAIN from send_frame() will not work
> > with current ffmpeg calling code.
> > I was assured that this will never happen but I don’t like possibility
> > of the failure.  What the calling code supposed to do getting EAGAIN
> > from send_frame()? Resubmit? If so it would not work with the logic
> > described.
> > Anyway, lets try Mark's suggestion and see if alternations are needed.
> 
> ffmpeg.c is written in a way that it calls receive_packet repeatedly until it 
> gets
> EAGAIN. Due to the API requirements I mentioned (send_frame and
> receive_packet both cannot return EAGAIN), it is OK to not handle EAGAIN
> for send_frame in ffmpeg.c code.
> 
> Other applications might use other logic (e.g. call send_frame repeatedly,
> and then call receive_packet once, or call send_frame and receive packet
> alternating), in these cases the user application must be able to handle
> EAGAIN for send_frame, and resubmit the frame next time.
> 
> But if ffmpeg.c gets an EAGAIN in send_frame, that means a bug in the
> encoder because the encoder is breaking the API and it needs to be fixed.

Yes, this is exactly how I understand it and hopefully implemented it.
 
> 
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks, Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Marton Balint]

On Tue, 31 Oct 2017, Mironov, Mikhail wrote:

[...]


I see some confusion. The user can call send_frame/receive_packet in any
order, and you can implement send_frame and receive_packet any way you
want, the only thing you have to guarantee is that you cannot return EAGAIN
for both send_frame and receive_packet. Not even temporarily.

If you returned EAGAIN in send_frame, you must return success or a normal
error in receive_packet. If you returned EAGAIN in receive_packet, you must
return success or a normal error in send_frame.

By returning EAGAIN in receive_packet you make sure that the API user
submits as many frames as needed to fill your pipeline.

The simplest solution really seems to me what Mark proposed:

send_frame:

if (have_stored_frame)
   return EAGAIN;
if (amd_send_frame() == INPUT_FULL)
   store_frame;
return 0;

receive_packet:

if (have_stored_frame) {
   if (amd_send_frame() == OK)
  unstore_frame;
   block_until_have_packet
   return packet
} else {
   return EAGAIN
}

I hope I did not mess it up, proper draining and error handling obviously
needs some minor changes.



The logic in receive_packet() will be slightly different but I will figure this 
out.
My only note is that returning EAGAIN from send_frame() will not work with
current ffmpeg calling code.
I was assured that this will never happen but I
don’t like possibility of the failure.  What the calling code supposed to do
getting EAGAIN from send_frame()? Resubmit? If so it would not work with
the logic described.
Anyway, lets try Mark's suggestion and see if alternations are needed.


ffmpeg.c is written in a way that it calls receive_packet repeatedly until 
it gets EAGAIN. Due to the API requirements I mentioned (send_frame and 
receive_packet both cannot return EAGAIN), it is OK to not handle EAGAIN 
for send_frame in ffmpeg.c code.


Other applications might use other logic (e.g. call send_frame repeatedly, 
and then call receive_packet once, or call send_frame and receive packet 
alternating), in these cases the user application must be able to handle 
EAGAIN for send_frame, and resubmit the frame next time.


But if ffmpeg.c gets an EAGAIN in send_frame, that means a bug in the 
encoder because the encoder is breaking the API and it needs to be fixed.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> >>> +AMF_ASSIGN_PROPERTY_BOOL(res, ctx->encoder,
> >> AMF_VIDEO_ENCODER_HEVC_DE_BLOCKING_FILTER_DISABLE,
> >> deblocking_filter);
> >>
> >> What about SAO?
> >
> > SAO ???
> 
> You're looking at AV_CODEC_FLAG_LOOP_FILTER to disable this, so you
> might want to consider both loop filters in H.265, not just the deblocking
> filter.
> 

At this point AMF exposes only deblocking filter.

> - 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Marton Balint
> Sent: October 30, 2017 9:26 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 
> 
> On Mon, 30 Oct 2017, Mironov, Mikhail wrote:
> 
> [...]
> 
>  I still think this would be much better off using the
>  send_frame()/receive_packet() API.  Even if your API doesn't expose
>  any information about the queue length, you only need to hold a
>  single input frame transiently to get around that (the user is not
>  allowed to call
>  send_frame() twice in a row without calling receive_packet()).
> 
> >>>
> >>> So to implement this I would have to:
> >>> - in the send_frame() if AMF_INPUT_FULL is returned - store input
> >>> frame (or copy?)
> >>> - In the next receive_frame() check if frame is stored
> >>> - Wait till some output is produced
> >>> - resubmit stored frame
> >>
> >> Sounds about right.
> >>
> >>> Issues I see:
> >>> - Isn't this logic defeat the purpose of independent send()/receive()?
> >>> - How can I report a error if receive() produced a compressed frame
> >>> but
> >> the delayed submission failed?
> >>
> >> Since this is asynchronous anyway, just report it at the next
> >> available opportunity.
> >>
> >>> - This logic depends on the particular logic in the calling code.
> >>
> >> The API requires this behaviour of the caller.  See the documentation
> >> in avcodec.h.
> >>
> >>> - This logic depends on the particular HW behaviour.
> >>
> >> How so?
> >>
> >>> - In the future, we would like to output individual slices of a
> >>> compressed
> >> frame.
> >>> When this added receive_frame() must be called several times to
> >>> clear
> >> space in the HW queue.
> >>> Granted, current implementation also does not cover this case but
> >>> truly independent send/receive implementation would.
> >>
> >> Note that the user is required to call receive_packet() repeatedly
> >> until it returns EAGAIN, and only then are they allowed to call
> send_frame() again.
> >
> > The implementation will be cumbersome at least. Note that calling
> > Drain() may also return AMF_INPUT_FULL and therefore will have to be
> > remembered and called again in receive(). But I will implement as you
> suggests. It is not a huge change.
> >
> 
> I see some confusion. The user can call send_frame/receive_packet in any
> order, and you can implement send_frame and receive_packet any way you
> want, the only thing you have to guarantee is that you cannot return EAGAIN
> for both send_frame and receive_packet. Not even temporarily.
> 
> If you returned EAGAIN in send_frame, you must return success or a normal
> error in receive_packet. If you returned EAGAIN in receive_packet, you must
> return success or a normal error in send_frame.
> 
> By returning EAGAIN in receive_packet you make sure that the API user
> submits as many frames as needed to fill your pipeline.
> 
> The simplest solution really seems to me what Mark proposed:
> 
> send_frame:
> 
> if (have_stored_frame)
>return EAGAIN;
> if (amd_send_frame() == INPUT_FULL)
>store_frame;
> return 0;
> 
> receive_packet:
> 
> if (have_stored_frame) {
>if (amd_send_frame() == OK)
>   unstore_frame;
>block_until_have_packet
>return packet
> } else {
>return EAGAIN
> }
> 
> I hope I did not mess it up, proper draining and error handling obviously
> needs some minor changes.
> 

The logic in receive_packet() will be slightly different but I will figure this 
out. 
My only note is that returning EAGAIN from send_frame() will not work with 
current ffmpeg calling code. I was assured that this will never happen but I
 don’t like possibility of the failure.  What the calling code supposed to do 
getting EAGAIN from send_frame()? Resubmit? If so it would not work with 
the logic described.
Anyway, lets try Mark's suggestion and see if alternations are needed.

> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks, Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Marton Balint]

On Mon, 30 Oct 2017, Mironov, Mikhail wrote:

[...]


I still think this would be much better off using the
send_frame()/receive_packet() API.  Even if your API doesn't expose
any information about the queue length, you only need to hold a
single input frame transiently to get around that (the user is not
allowed to call
send_frame() twice in a row without calling receive_packet()).



So to implement this I would have to:
- in the send_frame() if AMF_INPUT_FULL is returned - store input
frame (or copy?)
- In the next receive_frame() check if frame is stored
- Wait till some output is produced
- resubmit stored frame


Sounds about right.


Issues I see:
- Isn't this logic defeat the purpose of independent send()/receive()?
- How can I report a error if receive() produced a compressed frame but

the delayed submission failed?

Since this is asynchronous anyway, just report it at the next available
opportunity.


- This logic depends on the particular logic in the calling code.


The API requires this behaviour of the caller.  See the documentation in
avcodec.h.


- This logic depends on the particular HW behaviour.


How so?


- In the future, we would like to output individual slices of a compressed

frame.

When this added receive_frame() must be called several times to clear

space in the HW queue.

Granted, current implementation also does not cover this case but
truly independent send/receive implementation would.


Note that the user is required to call receive_packet() repeatedly until it
returns EAGAIN, and only then are they allowed to call send_frame() again.


The implementation will be cumbersome at least. Note that calling Drain()
may also return AMF_INPUT_FULL and therefore will have to be remembered and
called again in receive(). But I will implement as you suggests. It is not a 
huge change.



I see some confusion. The user can call send_frame/receive_packet in 
any order, and you can implement send_frame and receive_packet any way you 
want, the only thing you have to guarantee is that you cannot return 
EAGAIN for both send_frame and receive_packet. Not even temporarily.


If you returned EAGAIN in send_frame, you must return success or a 
normal error in receive_packet. If you returned EAGAIN in 
receive_packet, you must return success or a normal error in 
send_frame.


By returning EAGAIN in receive_packet you make sure that the API user 
submits as many frames as needed to fill your pipeline.


The simplest solution really seems to me what Mark proposed:

send_frame:

if (have_stored_frame)
  return EAGAIN;
if (amd_send_frame() == INPUT_FULL)
  store_frame;
return 0;

receive_packet:

if (have_stored_frame) {
  if (amd_send_frame() == OK)
 unstore_frame;
  block_until_have_packet
  return packet
} else {
  return EAGAIN
}

I hope I did not mess it up, proper draining and error handling obviously 
needs some minor changes.


Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> >>> +
> >>> +int ff_amf_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> >>> +const AVFrame *frame, int *got_packet) {
> >>> +int ret = 0;
> >>> +AMF_RESULT  res = AMF_OK;
> >>> +AmfContext *ctx = avctx->priv_data;
> >>> +AMFSurface *surface = NULL;
> >>> +AMFData*data = NULL;
> >>> +amf_bool   submitted = 0;
> >>> +
> >>> +while (!submitted) {
> >>> +if (!frame) { // submit drain
> >>> +if (!ctx->eof) { // submit drain onre time only
> >>> +res = ctx->encoder->pVtbl->Drain(ctx->encoder);
> >>> +if (res == AMF_INPUT_FULL) {
> >>> +av_usleep(1000); // input queue is full: wait,
> >>> + poll and submit
> >> Drain again
> >>> + // need to get some output and try 
> >>> again
> >>> +} else if (res == AMF_OK) {
> >>> +ctx->eof = 1; // drain started
> >>> +submitted = 1;
> >>> +}
> >>> +}
> >>> +} else { // submit frame
> >>> +if (surface == NULL) { // prepare surface from frame one time
> only
> >>> +if (frame->hw_frames_ctx && ( // HW frame detected
> >>> +  // check if the same
> >>> + hw_frames_ctx as used in
> >> initialization
> >>> +(ctx->hw_frames_ctx &&
> >>> + frame->hw_frames_ctx->data == ctx-
> >>> hw_frames_ctx->data) ||
> >>> +// check if the same hw_device_ctx as used in 
> >>> initialization
> >>> +(ctx->hw_device_ctx &&
> >>> + ((AVHWFramesContext*)frame-
> >>> hw_frames_ctx->data)->device_ctx ==
> >>> +(AVHWDeviceContext*)ctx->hw_device_ctx->data)
> >>> +)) {
> 
> (Here.)
> 
> >>> +ID3D11Texture2D* texture =
> >>> + (ID3D11Texture2D*)frame-
> >>> data[0]; // actual texture
> >>> +int index = (int)(size_t)frame->data[1]; //
> >>> + index is a slice in
> >> texture array is - set to tell AMF which slice to use
> >>
> >> (int)(intptr_t)frame->data[1];
> >>
> >>> +texture->lpVtbl->SetPrivateData(texture,
> >> , sizeof(index), );
> >>> +
> >>> +res =
> >>> + ctx->context->pVtbl->CreateSurfaceFromDX11Native(ctx-
> >>> context, texture, , NULL); // wrap to AMF surface
> >>> +surface->pVtbl->SetCrop(surface, 0, 0,
> >>> + frame->width, frame-
> >>> height); // decode surfaces are vertically aligned by 16 tell AMF
> >>> real size
> >>
> >> "decode surfaces"?  These need not come from a decoder.  Does it work
> >> with hwupload?
> >>
> >>> +surface->pVtbl->SetPts(surface, frame->pts);
> >>> +} else {
> >>> +res =
> >>> + ctx->context->pVtbl->AllocSurface(ctx->context,
> >> AMF_MEMORY_HOST, ctx->format, avctx->width, avctx->height,
> );
> >>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
> >>> + AVERROR_BUG,
> >> "AllocSurface() failed  with error %d \n", res);
> >>> +amf_copy_surface(avctx, frame, surface);
> >>> +}
> >>> +}
> >>> +// encode
> >>> +res = ctx->encoder->pVtbl->SubmitInput(ctx->encoder,
> >> (AMFData*)surface);
> >>> +if (res == AMF_INPUT_FULL) { // handle full queue
> >>> +av_usleep(1000); // input queue is full: wait, poll
> >>> + and submit
> >> surface again
> >>> +} else {
> >>> +surface->pVtbl->Release(surface);
> >>> +surface = NULL;
> >>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
> >> AVERROR_UNKNOWN, "SubmitInput() failed with error %d \n", res);
> >>> +submitted = 1;
> >>> +}
> >>> +}
> >>> +// poll results
> >>> +if (!data) {
> >>> +res = ctx->encoder->pVtbl->QueryOutput(ctx->encoder, );
> >>> +if (data) {
> >>> +AMFBuffer* buffer;
> >>> +AMFGuid guid = IID_AMFBuffer();
> >>> +data->pVtbl->QueryInterface(data, ,
> >>> + (void**)); //
> >> query for buffer interface
> >>> +ret = amf_copy_buffer(avctx, pkt, buffer);
> >>> +if (!ret)
> >>> +*got_packet = 1;
> >>> +buffer->pVtbl->Release(buffer);
> >>> +data->pVtbl->Release(data);
> >>> +if (ctx->eof) {
> >>> +submitted = 1; // we are in the drain state - no 
> >>> submissions
> >>> +}
> >>> +} else if (res == AMF_EOF) {
> >>> +submitted = 1; // drain complete
> >>> +} else {
> >>> +if (!submitted) {
> >>> +av_usleep(1000); // wait and poll again
> >>> +}
> >>> +}
> >>> +}
> >>> +}
> >>> 

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

Mikhail

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: October 30, 2017 6:19 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> 2017-10-30 18:56 GMT+01:00 mmironov :
> 
> [...]
> 
> > +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> > +AV_PIX_FMT_NV12,
> > +AV_PIX_FMT_0RGB32,
> > +AV_PIX_FMT_0BGR32,
> > +AV_PIX_FMT_YUV420P,
> > +AV_PIX_FMT_D3D11,
> > +AV_PIX_FMT_NONE
> > +};
> > +
> > +typedef struct FormatMap {
> > +enum AVPixelFormat   av_format;
> > +enum AMF_SURFACE_FORMAT  amf_format; } FormatMap;
> > +
> > +static const FormatMap format_map[] = {
> > +{ AV_PIX_FMT_NONE,   AMF_SURFACE_UNKNOWN },
> > +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },
> 
> > +{ AV_PIX_FMT_0BGR32,   AMF_SURFACE_BGRA },
> > +{ AV_PIX_FMT_0RGB32,   AMF_SURFACE_RGBA },
> 
> On little-endian, this is different from what you originally sent:
> Which one is correct? (Visually)

It should be RGB0 and BGR0 all the time. I will correct.

> 
> > +{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },
> 
> > +{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },
> 
> Please remove this line to reduce the confusion.
> (Or fix above if this line is correct.)


OK

> 
> > +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YV12 },
> > +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },
> 
> Do you agree that it is impossible that both lines are correct?

Agree. Will fix.

> 
> > +{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
> > +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },
> 
> Carl Eugen
> 
> [...]
> ___
> 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-10-30 23:35 GMT+01:00 Mark Thompson :
> On 30/10/17 21:30, Mironov, Mikhail wrote:
 +static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter
>>> *pThis,
 +const wchar_t *scope, const wchar_t *message)
 +{
 +AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
 +av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message);
>>>
>>> Does the message necessarily include a newline already?
>>
>> Yes.
>>
 +init_fun = (AMFInit_Fn)dlsym(ctx->library,
>>> AMF_INIT_FUNCTION_NAME);
 +AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN,
>>> "DLL %s failed to find function %s. \n", AMF_DLL_NAMEA,
>>> AMF_INIT_FUNCTION_NAME);
>>>
>>> I think do s/ \n/\n/ for all of these messages.
>>
>> Sorry, didn't get this.
>
> Most of your messages end with a space before the newline,
> the space probably shouldn't be there.

Correct: While I like the space, it shouldn't be there for
consistency.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 30/10/17 21:30, Mironov, Mikhail wrote:
>>> +static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter
>> *pThis,
>>> +const wchar_t *scope, const wchar_t *message)
>>> +{
>>> +AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
>>> +av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message);
>>
>> Does the message necessarily include a newline already?
> 
> Yes.
> 
>>> +init_fun = (AMFInit_Fn)dlsym(ctx->library,
>> AMF_INIT_FUNCTION_NAME);
>>> +AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN,
>> "DLL %s failed to find function %s. \n", AMF_DLL_NAMEA,
>> AMF_INIT_FUNCTION_NAME);
>>
>> I think do s/ \n/\n/ for all of these messages.
> 
> Sorry, didn't get this.

Most of your messages end with a space before the newline, the space probably 
shouldn't be there.

>>> +
>>> +version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library,
>> AMF_QUERY_VERSION_FUNCTION_NAME);
>>> +AMF_RETURN_IF_FALSE(ctx, version_fun != NULL,
>> AVERROR_UNKNOWN, "DLL %s failed to find function %s. \n",
>> AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
>>> +
>>> +res = version_fun(>version);
>>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s
>> failed with error %d. \n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
>>> +res = init_fun(AMF_FULL_VERSION, >factory);
>>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s
>> failed with error %d. \n", AMF_INIT_FUNCTION_NAME, res);
>>> +res = ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
>>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
>> "GetTrace() failed with error %d. \n", res);
>>> +res = ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
>>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
>> "GetDebug() failed with error %d. \n", res);
>>> +return 0;
>>> +}
>>> +
>>> +static int amf_init_context(AVCodecContext *avctx)
>>> +{
>>> +AmfContext *ctx = avctx->priv_data;
>>> +AMF_RESULT  res = AMF_OK;
>>> +
>>> +// the return of these functions indicates old state and do not affect
>> behaviour
>>> +ctx->trace->pVtbl->EnableWriter(ctx->trace,
>> AMF_TRACE_WRITER_CONSOLE, 0);
>>> +#if AMF_DEBUG_TRACE
>>> +ctx->trace->pVtbl->EnableWriter(ctx->trace,
>> AMF_TRACE_WRITER_DEBUG_OUTPUT, 1);
>>> +ctx->trace->pVtbl->SetWriterLevel(ctx->trace,
>> AMF_TRACE_WRITER_DEBUG_OUTPUT, AMF_TRACE_TRACE);
>>> +ctx->trace->pVtbl->SetGlobalLevel(ctx->trace, AMF_TRACE_TRACE);
>>> +#else
>>> +ctx->trace->pVtbl->EnableWriter(ctx->trace,
>> AMF_TRACE_WRITER_DEBUG_OUTPUT, 0);
>>> +#endif
>>
>> I don't much like this compile-time option.  What sort of messages does the
>> trace writer actually give you?  Will a user ever want to enable it?
> 
> Two points:
> 1. There is extensive AMF logging that can help diagnose a problem. Do we 
> want to have it all time in AV_LOG_DEBUG?
> 2. AMD can trace to debug output and this is useful but for normal ffmpeg 
> operation it is under #ifdef.

Help who diagnose a problem?  Either it is useful to a user, in which case put 
it behind a real option, or it isn't, in which case don't include it at all.  A 
compile-time option just encourages bitrot on whichever side is not default.

>>> +
>>> +static GUID  AMFTextureArrayIndexGUID =
>> AMFTextureArrayIndexGUIDDef;
>>
>> GUID is a Windows type, should this be AMFGuid?  (I tried removing the
>> check and compiling on Linux, other than the D3D11 stuff this is the only
>> error.)
>>
> 
> This is Windows type and used with Windows interface ID3D11Texture2D.
> When Linux support is added all this section will be under #ifdef.

It might be cleaner to put it inside the function (see below).  Also, it should 
be const.

>>> +
>>> +int ff_amf_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
>>> +const AVFrame *frame, int *got_packet)
>>> +{
>>> +int ret = 0;
>>> +AMF_RESULT  res = AMF_OK;
>>> +AmfContext *ctx = avctx->priv_data;
>>> +AMFSurface *surface = NULL;
>>> +AMFData*data = NULL;
>>> +amf_bool   submitted = 0;
>>> +
>>> +while (!submitted) {
>>> +if (!frame) { // submit drain
>>> +if (!ctx->eof) { // submit drain onre time only
>>> +res = ctx->encoder->pVtbl->Drain(ctx->encoder);
>>> +if (res == AMF_INPUT_FULL) {
>>> +av_usleep(1000); // input queue is full: wait, poll 
>>> and submit
>> Drain again
>>> + // need to get some output and try 
>>> again
>>> +} else if (res == AMF_OK) {
>>> +ctx->eof = 1; // drain started
>>> +submitted = 1;
>>> +}
>>> +}
>>> +} else { // submit frame
>>> +if (surface == NULL) { // prepare surface from frame one time 
>>> only
>>> +if (frame->hw_frames_ctx && ( // HW frame detected
>>> +   

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Carl Eugen Hoyos]

2017-10-30 18:56 GMT+01:00 mmironov :

[...]

> +const enum AVPixelFormat ff_amf_pix_fmts[] = {
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_0RGB32,
> +AV_PIX_FMT_0BGR32,
> +AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_D3D11,
> +AV_PIX_FMT_NONE
> +};
> +
> +typedef struct FormatMap {
> +enum AVPixelFormat   av_format;
> +enum AMF_SURFACE_FORMAT  amf_format;
> +} FormatMap;
> +
> +static const FormatMap format_map[] =
> +{
> +{ AV_PIX_FMT_NONE,   AMF_SURFACE_UNKNOWN },
> +{ AV_PIX_FMT_NV12,   AMF_SURFACE_NV12 },

> +{ AV_PIX_FMT_0BGR32,   AMF_SURFACE_BGRA },
> +{ AV_PIX_FMT_0RGB32,   AMF_SURFACE_RGBA },

On little-endian, this is different from what you originally sent:
Which one is correct? (Visually)

> +{ AV_PIX_FMT_GRAY8,  AMF_SURFACE_GRAY8 },

> +{ AV_PIX_FMT_BGR0,   AMF_SURFACE_BGRA },

Please remove this line to reduce the confusion.
(Or fix above if this line is correct.)

> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YV12 },
> +{ AV_PIX_FMT_YUV420P,AMF_SURFACE_YUV420P },

Do you agree that it is impossible that both lines are correct?

> +{ AV_PIX_FMT_YUYV422,AMF_SURFACE_YUY2 },
> +{ AV_PIX_FMT_D3D11,  AMF_SURFACE_NV12 },

Carl Eugen

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> > +static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter
> *pThis,
> > +const wchar_t *scope, const wchar_t *message)
> > +{
> > +AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
> > +av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message);
> 
> Does the message necessarily include a newline already?

Yes.

> > +init_fun = (AMFInit_Fn)dlsym(ctx->library,
> AMF_INIT_FUNCTION_NAME);
> > +AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN,
> "DLL %s failed to find function %s. \n", AMF_DLL_NAMEA,
> AMF_INIT_FUNCTION_NAME);
> 
> I think do s/ \n/\n/ for all of these messages.

Sorry, didn't get this.

> 
> > +
> > +version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library,
> AMF_QUERY_VERSION_FUNCTION_NAME);
> > +AMF_RETURN_IF_FALSE(ctx, version_fun != NULL,
> AVERROR_UNKNOWN, "DLL %s failed to find function %s. \n",
> AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
> > +
> > +res = version_fun(>version);
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s
> failed with error %d. \n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
> > +res = init_fun(AMF_FULL_VERSION, >factory);
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s
> failed with error %d. \n", AMF_INIT_FUNCTION_NAME, res);
> > +res = ctx->factory->pVtbl->GetTrace(ctx->factory, >trace);
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
> "GetTrace() failed with error %d. \n", res);
> > +res = ctx->factory->pVtbl->GetDebug(ctx->factory, >debug);
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN,
> "GetDebug() failed with error %d. \n", res);
> > +return 0;
> > +}
> > +
> > +static int amf_init_context(AVCodecContext *avctx)
> > +{
> > +AmfContext *ctx = avctx->priv_data;
> > +AMF_RESULT  res = AMF_OK;
> > +
> > +// the return of these functions indicates old state and do not affect
> behaviour
> > +ctx->trace->pVtbl->EnableWriter(ctx->trace,
> AMF_TRACE_WRITER_CONSOLE, 0);
> > +#if AMF_DEBUG_TRACE
> > +ctx->trace->pVtbl->EnableWriter(ctx->trace,
> AMF_TRACE_WRITER_DEBUG_OUTPUT, 1);
> > +ctx->trace->pVtbl->SetWriterLevel(ctx->trace,
> AMF_TRACE_WRITER_DEBUG_OUTPUT, AMF_TRACE_TRACE);
> > +ctx->trace->pVtbl->SetGlobalLevel(ctx->trace, AMF_TRACE_TRACE);
> > +#else
> > +ctx->trace->pVtbl->EnableWriter(ctx->trace,
> AMF_TRACE_WRITER_DEBUG_OUTPUT, 0);
> > +#endif
> 
> I don't much like this compile-time option.  What sort of messages does the
> trace writer actually give you?  Will a user ever want to enable it?

Two points:
1. There is extensive AMF logging that can help diagnose a problem. Do we want 
to have it all time in AV_LOG_DEBUG?
2. AMD can trace to debug output and this is useful but for normal ffmpeg 
operation it is under #ifdef.

> 
> > +
> > +static GUID  AMFTextureArrayIndexGUID =
> AMFTextureArrayIndexGUIDDef;
> 
> GUID is a Windows type, should this be AMFGuid?  (I tried removing the
> check and compiling on Linux, other than the D3D11 stuff this is the only
> error.)
> 

This is Windows type and used with Windows interface ID3D11Texture2D.
When Linux support is added all this section will be under #ifdef.

> > +
> > +int ff_amf_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
> > +const AVFrame *frame, int *got_packet)
> > +{
> > +int ret = 0;
> > +AMF_RESULT  res = AMF_OK;
> > +AmfContext *ctx = avctx->priv_data;
> > +AMFSurface *surface = NULL;
> > +AMFData*data = NULL;
> > +amf_bool   submitted = 0;
> > +
> > +while (!submitted) {
> > +if (!frame) { // submit drain
> > +if (!ctx->eof) { // submit drain onre time only
> > +res = ctx->encoder->pVtbl->Drain(ctx->encoder);
> > +if (res == AMF_INPUT_FULL) {
> > +av_usleep(1000); // input queue is full: wait, poll 
> > and submit
> Drain again
> > + // need to get some output and try 
> > again
> > +} else if (res == AMF_OK) {
> > +ctx->eof = 1; // drain started
> > +submitted = 1;
> > +}
> > +}
> > +} else { // submit frame
> > +if (surface == NULL) { // prepare surface from frame one time 
> > only
> > +if (frame->hw_frames_ctx && ( // HW frame detected
> > +  // check if the same 
> > hw_frames_ctx as used in
> initialization
> > +(ctx->hw_frames_ctx && frame->hw_frames_ctx->data == 
> > ctx-
> >hw_frames_ctx->data) ||
> > +// check if the same hw_device_ctx as used in 
> > initialization
> > +(ctx->hw_device_ctx && ((AVHWFramesContext*)frame-
> >hw_frames_ctx->data)->device_ctx ==
> > +(AVHWDeviceContext*)ctx->hw_device_ctx->data)
> > +)) {
> > +   

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 30/10/17 17:56, mmironov wrote:
> From 9337cb69176bc15aaaf74186cb3468f106236f04 Mon Sep 17 00:00:00 2001
> From: mmironov 
> Date: Fri, 27 Oct 2017 13:03:15 -0400
> Subject: [PATCH] Added: HW accelerated H.264 and HEVC encoding for AMD GPUs
>  based on AMF SDK
> 
> Signed-off-by: mmironov 
> ---
>  Changelog|3 +-
>  compat/amd/amfsdkenc.h   | 1750 
> ++
>  configure|   26 +
>  libavcodec/Makefile  |4 +
>  libavcodec/allcodecs.c   |2 +
>  libavcodec/amfenc.c  |  465 
>  libavcodec/amfenc.h  |  129 
>  libavcodec/amfenc_h264.c |  345 +
>  libavcodec/amfenc_hevc.c |  289 
>  libavcodec/version.h |4 +-
>  10 files changed, 3014 insertions(+), 3 deletions(-)
>  create mode 100644 compat/amd/amfsdkenc.h
>  create mode 100644 libavcodec/amfenc.c
>  create mode 100644 libavcodec/amfenc.h
>  create mode 100644 libavcodec/amfenc_h264.c
>  create mode 100644 libavcodec/amfenc_hevc.c
> 
> diff --git a/Changelog b/Changelog
> index 6592d86..f0d22fa 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,7 +6,8 @@ version :
>  - Dropped support for OpenJPEG versions 2.0 and below. Using OpenJPEG now
>requires 2.1 (or later) and pkg-config.
>  - VDA dropped (use VideoToolbox instead)
> -
> +- AMF H.264 encoder
> +- AMF HEVC encoder
>  
>  version 3.4:
>  - deflicker video filter
> diff --git a/compat/amd/amfsdkenc.h b/compat/amd/amfsdkenc.h
> ...
> diff --git a/configure b/configure
> index 0e1ccaa..c785cc9 100755
> --- a/configure
> +++ b/configure
> @@ -304,6 +304,7 @@ External library support:
>  
>The following libraries provide various hardware acceleration features:
>--disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
> +  --disable-amfdisable AMF video encoding code [autodetect]
>--disable-cuda   disable dynamically linked Nvidia CUDA code 
> [autodetect]
>--enable-cuda-sdkenable CUDA features that require the CUDA SDK 
> [no]
>--disable-cuvid  disable Nvidia CUVID support [autodetect]
> @@ -1641,6 +1642,7 @@ EXTERNAL_LIBRARY_LIST="
>  "
>  
>  HWACCEL_AUTODETECT_LIBRARY_LIST="
> +amf
>  audiotoolbox
>  crystalhd
>  cuda
> @@ -2785,12 +2787,16 @@ scale_npp_filter_deps="cuda libnpp"
>  scale_cuda_filter_deps="cuda_sdk"
>  thumbnail_cuda_filter_deps="cuda_sdk"
>  
> +amf_deps_any="dlopen LoadLibrary"
> +amf_encoder_deps="amf"

"amf_encoder" isn't mentioned anywhere else?

> +
>  nvenc_deps="cuda"
>  nvenc_deps_any="libdl LoadLibrary"
>  nvenc_encoder_deps="nvenc"
>  
>  h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
>  h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
> +h264_amf_encoder_deps="amf"
>  h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
>  h264_cuvid_decoder_deps="cuda cuvid"
>  h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
> @@ -2809,6 +2815,7 @@ 
> h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
>  h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
>  h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
>  h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
> +hevc_amf_encoder_deps="amf"
>  hevc_cuvid_decoder_deps="cuda cuvid"
>  hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
>  hevc_mediacodec_decoder_deps="mediacodec"
> @@ -6305,6 +6312,18 @@ else
>  disable cuda cuvid nvenc
>  fi
>  
> +if enabled x86; then
> +case $target_os in
> +mingw32*|mingw64*|win32|win64|cygwin*)
> +;;
> +*)
> +disable  amf
> +;;
> +esac
> +else
> +disable amf
> +fi
> +
>  enabled nvenc &&
>  check_cc -I$source_path <  #include "compat/nvenc/nvEncodeAPI.h"
> @@ -6313,6 +6332,13 @@ void f(void) { struct { const GUID guid; } s[] = { { 
> NV_ENC_PRESET_HQ_GUID } };
>  int main(void) { return 0; }
>  EOF
>  
> +enabled amf &&
> +check_cc -I$source_path < +#include "compat/amd/amfsdkenc.h"
> +AMFFactory *factory;
> +int main(void) { return 0; }
> +EOF
> +
>  # Funny iconv installations are not unusual, so check it after all flags 
> have been set
>  if enabled libc_iconv; then
>  check_func_headers iconv.h iconv
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index bc4d7da..cbf45ac 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -50,6 +50,7 @@ OBJS = allcodecs.o  
> \
>  # subsystems
>  OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
>  OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
> +OBJS-$(CONFIG_AMF) += amfenc.o
>  OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
>  OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
>  OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
> @@ -334,6 +335,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
> h264_cabac.o h264_cavlc.o \
>