[FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer copies are done before submitting them
Soft Works
softworkz at hotmail.com
Tue Aug 11 14:08:13 EEST 2020
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Steve Lhomme
> Sent: Tuesday, August 11, 2020 12:44 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 1/2] dxva: wait until D3D11 buffer
> copies are done before submitting them
> Even though the discussion is heated (fitting with the weather here) I don't
> mind. I learned some stuff and it pushed me to dig deeper. I can't just accept
> your word for it. I need something solid if I'm going to remove a lock that
> helped me so far.
You're not supposed to accept my word. I wouldn’t do either. You could have
just valued it as a possibility..that's all.
> So I'm currently tooling VLC to be able to bring the decoder to its knees and
> find out what it can and cannot do safely. So far I can still see decoding
> artifacts when I don't a lock, which would mean I still need the mutex, for the
> reasons given in the previous mail.
Are you actually using D3D11 staging textures? I'm still not clear about
that "old-api" way.
I'm curious: what's your motivation for using D3D11 over D3D9?
I mean, we are always transcoding without rendering a video to any surface.
Our reasons to use D3D11 are these two:
1. Works headless (without connected display)
2. Works without user session (like inside a Windows service)
What's yours?
When implementing D3D11 for QuickSync I managed to get very close to
DXVA2 performance eventually, but I hardly ever have been able to exceed it..
PS: Yes, it's damn hot here as well! :-)
Kind regards,
softworkz
More information about the ffmpeg-devel
mailing list