[FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling d3d11va support, added mfxhdlpair

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Max Dmitrichenko
> Sent: Thursday, 15 July 2021 17:15
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> d3d11va support, added mfxhdlpair
> 
> On Thu, Jul 15, 2021 at 5:49 AM Soft Works <softworkz at hotmail.com> wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > James Almer
> > > Sent: Thursday, 15 July 2021 05:21
> > > To: ffmpeg-devel at ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv: enabling
> > > d3d11va support, added mfxhdlpair
> > >
> > > On 7/15/2021 12:10 AM, Soft Works wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf
> Of
> > > >> Xiang, Haihao
> > > >> Sent: Thursday, 15 July 2021 04:35
> > > >> To: ffmpeg-devel at ffmpeg.org
> > > >> Subject: Re: [FFmpeg-devel] [PATCH v7 1/8] libavcodec/qsv:
> > > >> enabling d3d11va support, added mfxhdlpair
> > > >>
> > > >> On Tue, 2021-07-13 at 11:53 -0300, James Almer wrote:
> > > >>> On 11/14/2020 1:49 PM, Max Dmitrichenko wrote:
> > > >>>> On Tue, Nov 3, 2020 at 7:47 PM Artem Galin
> > > >>>> <artem.galin at gmail.com>
> > > >> wrote:
> > > >>>>
> > > >>>>> Adding DX11 relevant device type checks and adjusting
> > > >>>>> callbacks with proper MediaSDK pair type support.
> > > >>>>>
> > > >>>>> Extending structure for proper MediaSDK pair type support.
> > > >>>>>
> > > >>>>> Signed-off-by: Artem Galin <artem.galin at intel.com> .....
> > > >>>>
> > > >>>>
> > > >>>> Patchset obviously closes the gap of DirectX 11 support and
> > > >>>> already checked with several apps that use FFMPEG.
> > > >>>>
> > > >>>> Any particular review comments should be yet expected?
> > > >>>>
> > > >>>> Changes seem to be straight forward and incorporate prev.
> comments.
> > > >>>>
> > > >>>> thank in advance
> > > >>>>
> > > >>>> regards
> > > >>>> Max
> > > >>>
> > > >>> There are some issues pointed out by Soft Works related to
> > > >>> switching the default to DX11 breaking existing command lines
> > > >>> with DX9, plus an OpenCL<->QSV interop regression this would
> > > >>> introduce that according to him should be easy to fix.
> > > >>>
> > > >>> If those are addressed, the set should be good.
> > > >>
> > > >> If we may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021-
> > > >> June/281778.html
> > > >> (qsvdec: add support for HW_DEVICE_CTX method) first, we should
> > > >> be able to use the common device stuff to initialize d3d11va
> > > >> device for QSV and needn't use child_device_type to specify child
> device.
> > > >
> > > > There's no doubt that the new method will be better, but the point
> > > > is
> > not
> > > to break existing command lines. From my experience, ffmpeg usually
> > avoids
> > > to break established command line patterns, which is a good thing imo.
> > > >
> > > > Anything more official than my perception? Please feel free to
> > > > chime in... ;-)
> > >
> > > That patch appears to attempt to maintain support for existing
> > > command lines for a deprecation period, something we've done before
> > > with other hwaccels like cuvid, so if it's really better, it's fine and
> acceptable.
> > ^
> >
> > Hi James,
> >
> > "That patch" that preserves compatibility doesn't exist yet. We need
> > to make sure that command lines using the '--child_device' parameter
> > will continue to work, while Haihao's patch will be the "future way":
> >
> > > -init_hw_device d3d11va=d3d11va:xxx -init_hw_device qsv at d3d11va
> >
> > The new behaviour that is introduced by this patch is that an
> > initialized hw device can now be applied to qsv decoders (currently
> > only to filter graphs and qsv encoders).
> >
> > Additionally, the default should remain to be D3D9 (if none of the
> > above is specified) as laid out earlier - again for maintaining
> > compatibility but also for better robustness and performance.
> >
> >
> Upon introduction of DX11/D3D11VA support, it makes sense to make it
> default as well, this would help for upcoming implementations and general
> usages in the long run, including new usages, as headless platforms support,
> which is an obvious D3D9 gap, as an example.
> 
> Compatibility is still preserved and available with D3D9 path, there is no
> functional change.
> If D3D9 is critical for further usage - it has to be requested explicitly.

Which is a breaking change. It would not only affect a huge amount of applications and users - it would also invalidate thousands of command parameter examples that are spread all over the web.

I'd love to hear some other voices on this (even when opinions differ). 
I don't want to be the only one opposing it each time..

softworkz