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

[Max Dmitrichenko]

On Sat, May 9, 2020 at 10:26 PM Soft Works <softworkz at hotmail.com> wrote:

> > -----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.
>
>
not sure where it goes:  if a user uses new version - there are new aspects
to consider


> > > 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?
>
>
there should be no secrets here - implementation is available,
do you see fallback implementation?

we shouldn't forget that target app that uses FFMPEG can have the own
preferences
and configuration,
with this patch - it is possible to use DX11, unlike before.


> 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
> _______________________________________________
>
>

regards
Max