[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
> Max Dmitrichenko
> Sent: Saturday, May 9, 2020 10:13 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 8:31 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 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)
> >
> >
> This switch is documented and explained with reasons.
> a normal ffmpeg command line user has no association like with headless HW
> setup and DX11.

You can document that wherever you want, but for existing users, 
command lines that have always been working before will stop working
in a significant number 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).
> >
> >
> behavior stays deterministic with option for explicit selection of DX version.
> also, no drop of DX9 is considered.

That was primarily a response to Hendrik's thought about automatically
falling back to D3D9.

But still, even with your patch: What will happen when DX11 is not available?

Will it 

1. fail?
2. or will it use D3D9 instead?

In case of 2, it's non-deterministic, and when the user has specified an 
adapter number for DX11, it might use the wrong adapter when ffmpeg 
uses D3D9 instead (because D3D9 and DX11 are counting adapters differently)

Regards,
softworkz