> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Steve Lhomme > Sent: Tuesday, August 11, 2020 12:44 PM > To: ffmpeg-devel@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 _______________________________________________ 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".
