[FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for HW_DEVICE_CTX method

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Xiang, Haihao
> Sent: Monday, 2 August 2021 07:53
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
> 
> On Fri, 2021-07-30 at 08:18 +0000, Soft Works wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Haihao Xiang
> > > Sent: Thursday, 29 July 2021 09:04
> > > To: ffmpeg-devel at ffmpeg.org
> > > Cc: Haihao Xiang <haihao.xiang at intel.com>
> > > Subject: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> > > HW_DEVICE_CTX method
> > >
> > > This allows user set hw_device_ctx instead of hw_frames_ctx for QSV
> > > decoders, hence we may remove the ad-hoc libmfx setup code from
> > > FFmpeg.
> > >
> > > "-hwaccel_output_format format" is applied to QSV decoders after
> > > removing the ad-hoc libmfx code. To keep compatibility with old
> > > commandlines, the default format is set to AV_PIX_FMT_QSV. User
> > > should set "- hwaccel_output_format qsv" explicitly if AV_PIX_FMT_QSV
> is expected.
> > >
> > > User may use the normal way to set device for QSV decoders now.
> > > "-qsv_device device" is deprecated and will be removed from FFmpeg.
> > >
> > > For example:
> > >
> > > $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device
> > > qsv=hw at va -hwaccel qsv -c:v h264_qsv -i input.h264 -f null -
> >
> > Hi Haihao,
> >
> > Why so complicated with double device initialization?
> > The regular way is this:
> >
> > ffmpeg -init_hw_device "qsv=dev:hw_any,child_device=/dev/dri/card0"
> > -hwaccel qsv -c:v h264_qsv -i input.h264 -f null -
> >
> > Or for Windows:
> >
> > ffmpeg -init_hw_device "qsv=dev:hw_any,child_device=1" -hwaccel qsv
> > -c:v h264_qsv -i input.h264 -f null -
> 
> After applying this patch, the above commands may work too, actually a child
> device is created internally in this way, then a QSV device is derived from the
> child device implicitly. However deriving a device explicitly creates a
> connection between source device and derived device. We may derive a
> new device of the source type from the derived device.

"may work too" is not sufficient. The existing and documented method must 
continue to work.

Besides that, it doesn't make sense to me to start advertising those overcomplicated
command lines with double device initialization as the default way for using QSV.

> 
> e.g.
> 
> The command below works
> 
> $> ffmpeg -init_hw_device vaapi=intel:/dev/dri/renderD128 -init_hw_device
> qsv=qsv at intel -hwaccel qsv -c:v h264_qsv -i input.h264 -vf
> hwmap=derive_device=vaapi,scale_vaapi -f null -
> 
> but the command below doesn't work
> 
> $> ffmpeg -init_hw_device
> qsv=dev:hw_any,child_device=/dev/dri/renderD128
> -hwaccel qsv -c:v h264_qsv -i ~/graphics/movies/720p.mp4 -vf
> hwmap=derive_device=vaapi,scale_vaapi -f null -
> 
> (We may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021-
> February/276695.html
>  to create a connection between two devices too, but this change breaks
> 'make fate-hwdevice V=2').

I had done a similar patch quite a while ago, just forgot about it,
so yes, that patch is crucial as well.

softworkz