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

The (similar) implementation that I have done, is running on fine on thousands 
of installations for about a year now. 
With the currently proposed solution, we would be unable to ship the product.

Best regards,

softworkz