[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 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.
Even, as stated below, discrete graphics adapters setup will benefit from
default'ing to DX11.

it has to be reasonable decision but not purely focusing on support of
somehow aged HW,
before 6th Gen Intel(R) Core(TM) processor family (Codename Skylake).


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


> 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).
>
>
are there prepared patch to consider?


> 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
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".



regards
Max