[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
> Soft Works
> Sent: Friday, 6 August 2021 10:26
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > Xiang, Haihao
> > Sent: Friday, 6 August 2021 10:01
> > To: ffmpeg-devel at ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] qsvdec: add support for
> > HW_DEVICE_CTX method
> >
> >
> > > On Wed, 2021-08-04 at 10:10 +0000, Soft Works wrote:
> > > > Haihao,
> > > >
> > > > I've just been looking into the source patch from February:
> > > >
> > > > > > > (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've re-read the discussion about why it fails Fate and I actually
> > > > _think_ that it might not fail anymore with your (this) patch applied.
> > > >
> > > > To test, it would probably be required to submit a combined patch,
> > > > unless you'd have your own Fate server to test..
> > > >
> > >
> > > I also thought the issue should disappear after applying my patch
> > > and
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276695.html,
> > > however my testing shows 'make fate-hwdevice V=2' still fails. I ran
> > > the fate test on my local machine.
> >
> > Hi Softworks,
> >
> > I think Mark's comment is not about fixing issue after applying
> > #276695, instead it is about fixing/workarounding the original issue in other
> ways.
> >
> > After applying #276695, user may derive a QSV device to a VAAPI device
> > however user can't derive this VAAPI device back to the original QSV
> > device, so fate- hwdevice fails. My patch is not related to hw device
> > creation/derivation, fate- hwdevice still fails even if applying my patch.
> >
> > If we can't apply #276695, do you agree to use double device
> > initialization instead of single-shot initialization to handle -qsv_device
> option ?
> 
> No, I don't. The patch setting the ->source value is essential for being able to
> derive an OpenCL from a QSV context, which is the reason why I had added it
> even before the patch from your colleague had been submitted.
> 
> One part of Marks comments was caused by the fact that the supplied
> command line was wrong and the other part was about what Mark had called
> "hacks" for QSV. Those "hacks" are removed by your patch now.
> When there's still a Fate error we need to check out the reason, but I'm not
> familiar with running Fate.
> 
> I ran this:
> 
> make fate-rsync SAMPLES=fate-suite/
> make fate       SAMPLES=fate-suite/
> 
> It took a long time but it didn't return any error.
> 
> Then I ran this:
> 
> make fate-hwdevice V=2
> 
> Which built an executable: hwdevice.exe
> 
> Finally, running hwdevice.exe returned:
> 
> Attempted to test 5 device types: 5 passed, 0 failed, 0 skipped.
> 
> 
> Either I've done something wrong in Fate execution or the error doesn't exist
> in my code base for some reason.
> 
> I have already changed the code in qsvdec to single-shot initialization, have
> you done the same?
> 

Hi Haihao,

The test passed in my case because I had another hack in place.

I have done and submitted a proper implementation now. It combines the patch 
from Guangxin Xu https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210222084504.339978-1-guangxin.xu@intel.com/
with better handling of device derivation:

https://patchwork.ffmpeg.org/project/ffmpeg/patch/BYAPR04MB597605B1168D1F04AD6D36A7BAF49@BYAPR04MB5976.namprd04.prod.outlook.com/

softworkz