On Sat, May 9, 2020 at 10:26 PM Soft Works <softwo...@hotmail.com> wrote:
> > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:13 PM > > To: FFmpeg development discussions and patches <ffmpeg- > > de...@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 <softwo...@hotmail.com> wrote: > > > > > > -----Original Message----- > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > > > > Hendrik Leppkes > > > > Sent: Saturday, May 9, 2020 7:54 PM > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > de...@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 <softwo...@hotmail.com> > > wrote: > > > > > > > > > > > -----Original Message----- > > > > > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On > > Behalf > > > > > > Of Hendrik Leppkes > > > > > > Sent: Saturday, May 9, 2020 9:08 AM > > > > > > To: FFmpeg development discussions and patches <ffmpeg- > > > > > > de...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
