[FFmpeg-devel] [PATCH v7 2/8] libavutil/hwcontext_qsv: supporting d3d11va device type

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Artem Galin
> Sent: Tuesday, November 3, 2020 7:46 PM
> To: ffmpeg-devel at ffmpeg.org
> Cc: Artem Galin <artem.galin at intel.com>
> Subject: [FFmpeg-devel] [PATCH v7 2/8] libavutil/hwcontext_qsv: supporting
> d3d11va device type
> 
> This enables usage of non-powered/headless GPU, better HDR support.
> Pool of resources is allocated as one texture with array of slices.
> 
> Signed-off-by: Artem Galin <artem.galin at intel.com>
> ---
>  libavutil/hwcontext_qsv.c | 323 +++++++++++++++++++++++++++++++----
> ---
>  1 file changed, 262 insertions(+), 61 deletions(-)
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index
> 35a944f8f8..1f5a3d1c57 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -27,9 +27,13 @@


Hi Artem,

A while ago I had merged and aligned your v7 patch in order to become equal
and to verify the patch. There has been one scenario that didn't work anymore,
but I just can remember what it was exactly. That means unfortunately that I
can't proof this by providing an exact repro case.

But it must have been one of the following:

- hwdownload from a QSV filter
- hwupload to a QSV filter
- hwupload to a QSV encoder
- hybrid pipeline with D3D11VA decoder
  - deriving to QSV encoder ... or
  - deriving to QSV filter

At least I know the reason: you had simplified my qsv_get_d3d11va_bind_flags
function, and some tiny bit of the logic got lost by doing so.

I apologize for being a bit vague, I should have made some notes when I had
seen it. I hope it is still useful in some way.

Kind regards,
softworkz