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

[Xiang, Haihao]

On Thu, 2021-07-15 at 03:49 +0000, Soft Works 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).

'-init_hw_device qsv=qsv:hw,child_device=xxx' still works,

e.g. /dev/dri/renderD129 is used for both qsv decoder and encoder on Linux when
running the command below on a HW with multiple GPUs.

$> ffmpeg -y -init_hw_device qsv=qsv:hw,child_device=/dev/dri/renderD129
-hwaccel qsv -c:v hevc_qsv -i input.265 -c:v hevc_qsv -f rawvideo out.h265

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

We may refine Artem's patch to make sure the default is D3D9 on Microsoft
windows when both dxva2 and d3d11va are enabled if applying my patch first. 

Thanks
Haihao


> 
> PS: Regarding the OpenCL regression you mentioned, I had already submitted the
> patch to Intel and they have added it to their staging-repo for ffmpeg
> patches: 
> https://github.com/intel-media-ci/cartwheel-ffmpeg/commit/7456b1ac0d385acc6d2851470c1b04ab3780adf8
> 
> Kind regards,
> 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".