[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: 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?

softworkz