Hi all, I'd like to have video (and audio) capture while playing, what encoder would have minimal impact on gameplay while giving decent quality @1080 (60Hz a plus) ? The game I'm interested into is bike racing sim (openGL, if that makes a difference). Recording time could be pretty long (let's say 1h max), so file size can't go totally nuts, even if I may not mind too much re-encoding after capture. Up to now I've tried the AMD VCE (thx to Unwinder for RTSS 6.4.0 restoring it) and Intel QuickSync, but the impact on gameplay is still noticeable. I don't need streaming, only video capture. MaX.
If you render the game with your AMD card and use Quicksynch for capturing there should not be a noticeable impact?!
But there is, with both QuickSync and VCE (*): in my game I get a very important fps drop. Oddly, using OBS the drop is much much smaller (under same conditions for both: iQSV, same bitrate, same fps, same output resolution etc). MaX. (*) When VCE was working for me, at the moment, with RTSS 6.4.0, I get audio but no video.
You've got quite typical and wrong understanding of video capture process basics. The encoder has close to zero relation to in-game performance hit during videocapture. The main performance offender is a frame capture process. In your specific case (AMD platform and OpenGL application) frame capture performance can be improved via enabling OpenGL PBO extension, allowing asynchronous DMA copy of frame buffer. However, I'd think twice before enabling it on AMD cards - it is disabled by default because the quality of AMD OpenGL ICD is far from being ideal and PBO extension usage may cause serious stability problem during videocapture on some systems. If you still decide to enable it - edit .\ProfileTemplates\Global file, find [ScreenCaptureOpenGL] section and change PBOATI to 1.
Thanks for the reply Unwinder. By pure chance, I've read your post explaining what drives performance (and how the encoder has limited impact) just 2 weeks ago. So yes, I should have formulated my question into something like "which settings in AB I can use to minimize impact on gameplay while capturing video ?". Thing is that when using AB+iQSV I do have an important FPS drop in GP Bikes (which is rather light on the GPU and CPU usage by the way). I've just tried out OBS and with the same settings (iQSV, same bitrate etc), the FPS drop is much smaller for an almost identical result (file size and quality). Is that normal or is it something specific to my situations (don't know, maybe the fact the game is openGL) ? I'd like to avoid having to run a 2nd program just for video capture, if there's a way to squeeze out the same performance from AB.
I wanted to post here an follow up. I'm experience some performance hits as well when trying to record. Here are my benchmarks at 16:9 720p QSV.dll:0 - Intel QuickSync H.264 - Balanced - 20Mbps target " Intel QuickSync H.264 hardware accelerated via Direct3D11 on adapter 2, async depth 4 1280x720: 500 frames have been encoded in 2203ms, 227.0 fps." AMDAMF.dll:0 - AMD VCE H.264 - Balanced - 20Mbps target "AMD VCE H.264 hardware accelerated via AMD AMF on Direct3D9 device 0 1280x720: 500 frames have been encoded in 2969ms, 168.4 fps." I'm not sure how my i5 2500k could be better than and R9 290 at encoding unless these benchmarks are somehow wrong. On 15.11 drivers. Tested with both PBOATI on and off. No huge difference.
For me the "PBO trick" described by Unwinder improved the performances of the VCE encoder (with no apparent stability issue). Still, the in-game the fps drop is bigger than what I see with OBS. Not a big deal for me personally.
"PBO trick" has zero relation to ENCODER performance. It doesn't affect anything but OpenGL frame caprture performance. You are not supposed to see ANY difference in encoder benchmark when toggling it. And yes, Intel QuckSync was always the fastest when comparing it to NVENC and VCE. Actually VCE is the slowest of those 3 hardware implementations.
I saw the difference while capturing in-game (open-gl game), not in the benchmark (sorry I didn't make this clear in my previous post).
