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

[Xiang, Haihao]

On Mon, 2021-08-02 at 07:11 +0000, Soft Works wrote:
> > -----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.

Could you please provide an example which is broken by this patch? I don't seeregression in my testing. 

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

This patch doesn't advertise that double device initialization is the default
way for QSV. I just use it as an example in the commit log, I may add another
example in the commit log if needed. 

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

Let's fix it in another patch if the above command is expected to work too. 

Thanks
Haihao