> 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 ? Thanks Haihao _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
