[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