[FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Hendrik Leppkes
> Sent: Saturday, May 9, 2020 7:54 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture information to the D3D11 hwcontext API
> 
> On Sat, May 9, 2020 at 7:41 PM Soft Works <softworkz at hotmail.com> wrote:
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Hendrik Leppkes
> > > Sent: Saturday, May 9, 2020 9:08 AM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> libavutil/hwcontext_d3d11va:
> > > adding more texture information to the D3D11 hwcontext API
> > >
> >
> > > > >
> > > > > I'm not really a fan of this. Only supporting array textures was
> > > > > an intentional design decision back when D3D11VA was defined,
> > > > > because it greatly simplified the entire design - and as far as
> > > > > I know the d3d11va decoder, for example, doesnt even support
> > > > > decoding into
> > > anything else.
> > > > >
> > > > > - Hendrik
> > > >
> > > > It's not like there would be a choice. The Intel MSDK uses an
> > > > allocator mechanism and when it asks for a non-array DX11 texture
> > > > it has to
> > > be given one.
> > > >
> > >
> > > Of course there is a choice. Only support the new stuff. Afterall we
> > > havent supported it at all for years now, so only supporting it on
> > > newer drivers isn't the end of the world.
> >
> > It _IS_ the end of the world when at the same time, the default will
> > be switched to DX11 because this will automatically create many cases
> > where things will fail which have been working previously.
> >
> > An automatic fallback is not a good alternative either because that
> > would break specific adapter selection by adapter number because the
> > numbering is different between D3D9 and DX11.
> >
> > Assuming that everybody would have the latest driver is not matching
> > the situation in the real world. See here for an example:
> > https://github.com/softworkz/ffmpeg_dx11/issues/1
> >
> 
> According to your own documentation, even the proposed DX11 version will
> still fail on various systems (only bullet point 3 is solved from the list in issue
> 2, leaving 1 and 2) So either you have a fallback, or DX11 should probably just
> not be the default at all then.

From a perspective of a normal ffmpeg command line user, my position is
that DX11 should not be made the default because it will break command 
lines that have been working before. (in a significant amount of cases)

Even more important, though: The behavior should be deterministic, which 
means that ffmpeg should not make an automatic decision (consider the 
device selection by adapter number).

Intel discrete graphic adapters are coming this year, so device selection 
will become even more important than before as you will be able to have
even multiple Intel graphics adapters.

Regarding your question above ("only the 3rd bullet point is addressed"): 
We implemented  a comprehensive device detection which gives us detailed
Information about all hardware devices, their drivers, supported codecs and
capabilities. 
This allows us to detect Intel adapters having drivers below MSDK version 1.21,
and for those we're using D3D9 only.

But for all other versions (MSDK 1.21 to 1.31), we _want_ to be able to use
DX11 because it allows using without a connected display and without an
active user session (e.g. Windows service). 

So, the impact is two-fold:
- We would be in the position to choose D3D9, but we "want" to have it
  working on all the other driver versions
- For a regular user, who cannot easily determine the MSDK version (or should
  not be needed to bother doing so), the resulting ffmpeg behavior would  
  be failure in a lot of cases

softworkz