Question / Help Why does Local Recording with a Capture Card Suck?

[Zero32]

Bullet points in bold.

I've spent the past couple years trying to improve the quality and smoothness of my videos, doing everything from recording with Fraps and compressing the videos later, to spending several thousand dollars to build various PCs and installing them with PCIe capture cards.

My most recent experiences revolve around the AverMedia Live Gamer HD C985 and an older build of OBS that I was happy with. I discovered I could local record to another PC with the C985 in it and achieve 1080p 30fps recordings that looked both beautiful and played back smoothly using custom x264 settings of crf=16 keyint=60 min-keyint=25 and I was pleased with it.

To get to the point, various updates happened to OBS and I slowly noticed that my recordings were starting to "jitter" ... a lot. Thinking that it was due to the updates I switched to an older version of OBS but still experienced the same problem.

I figured the C985 was dieing so I went for an upgrade and chose the XCAPTURE-1, an external capture card capable of 1080p 60fps recording. I also updated my system with two 3TB hard drives in Raid 0 figuring I needed the extra sustained write to do 60fps at 1080p.

Once again, nothing changed and, in fact, the problem was only getting worse...

In the end I ripped out my GTX670 figuring the card wasn't transmitting the frames to the capture card correctly (I was right, it wasn't but that's not the problem...), and in frustration I decided to play the game I was trying to record on my recording PC but use "Game Capture" instead with no changes to my x264 preset whatsoever... and the problem was non-existant... in fact, I used a total of 67% CPU power on average using Game Capture mode, while my capture card while recording would use 90-100%! What is going on?!

So my question is, will I ever be able to use my capture card correctly with OBS or is using one the same as trying to capture with Window Capture?

To put this in perspective, I can capture using crf=0 in Game Capture mode without any frames lost, but OBS completely fails to capture more than one frame every 10 seconds while using the capture card (either the C985 or XCAPTURE-1...).

 

[Sapiens]

I discovered I could local record to another PC with the C985 in it and achieve 1080p 30fps recordings that looked both beautiful and played back smoothly using custom x264 settings of crf=16 keyint=60 min-keyint=25 and I was pleased with it.

crf=16 is the only custom param that really makes sense for a local recording here. Hopefully you were using VBR and a vbv-bufsize value of 0.

To get to the point, various updates happened to OBS and I slowly noticed that my recordings were starting to "jitter" ... a lot.

You should probably explain what that means in more detail.

in fact, I used a total of 67% CPU power on average using Game Capture mode, while my capture card while recording would use 90-100%! What is going on?!

Capture cards aren't meant to improve performance unless you use one with a hardware encoder, which OBS doesn't support anyway. However they also shouldn't hinder performance that severely either. A log file from a recording that experienced the issue would be useful in diagnosing the problem - viewtopic.php?f=5&t=7144

 

[Zero32]

crf=16 is the only custom param that really makes sense for a local recording here. Hopefully you were using VBR and a vbv-bufsize value of 0.

I use the keyint=60 min-keyint=25 because that allows me to not only view how the video files turned out faster, it also allows me to edit them in a program like Adobe Premiere a lot easier. I had CBR checked with a custom buffer of 0 which I believe achieves the same thing as what you're stating.

To get to the point, various updates happened to OBS and I slowly noticed that my recordings were starting to "jitter" ... a lot.

You should probably explain what that means in more detail.

By "jittering" I mean that the video will go from smooth playback to stuttering every other frame (it hangs and then skips a few frames to catch up resulting in the appearance of a "jitter.").

in fact, I used a total of 67% CPU power on average using Game Capture mode, while my capture card while recording would use 90-100%! What is going on?!

Capture cards aren't meant to improve performance unless you use one with a hardware encoder, which OBS doesn't support anyway. However they also shouldn't hinder performance that severely either. A log file from a recording that experienced the issue would be useful in diagnosing the problem - https://obsproject.com/forum/viewtopic.php?f=5&t=7144

If the capture card is connected to a PC, who's only purpose in life is to take streamed video from a Gaming PC through the capture card and encode it, wouldn't that be 10 times better than encoding on the same PC that you're playing the game on?

I also expected that log request to appear at some point:

01:02:46: Open Broadcaster Software v0.584b - 32bit (´・ω・｀)
01:02:46: -------------------------------
01:02:46: CPU Name: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
01:02:46: CPU Speed: 3418MHz
01:02:46: Physical Memory:  4095MB Total, 4095MB Free
01:02:46: stepping id: 7, model 42, family 6, type 0, extmodel 1, extfamily 0, HTT 1, logical cores 8, total cores 4
01:02:46: monitor 1: pos={0, 0}, size={1920, 1080}
01:02:46: Windows Version: 6.2 Build 9200 
01:02:46: Aero is Enabled
01:02:46: -------------------------------
01:02:46: OBS Modules:
01:02:46: Base Address     Module
01:02:46: 01190000         OBS.exe
01:02:46: 677C0000         OBSApi.dll
01:02:46: 67DA0000         DShowPlugin.dll
01:02:46: 67530000         GraphicsCapture.dll
01:02:46: 67510000         NoiseGate.dll
01:02:46: 67440000         PSVPlugin.dll
01:02:46: ------------------------------------------
01:02:46: Adapter 1
01:02:46:   Video Adapter: NVIDIA GeForce GTX 570
01:02:46:   Video Adapter Dedicated Video Memory: 1286533120
01:02:46:   Video Adapter Shared System Memory: 2952671232
01:02:46:   Video Adapter Output 1: pos={0, 0}, size={1920, 1080}, attached=true
01:02:46: =====Stream Start: 2013-12-09, 01:02:46===============================================
01:02:46:   Multithreaded optimizations: On
01:02:46:   Base resolution: 1920x1080
01:02:46:   Output resolution: 1920x1080
01:02:46: ------------------------------------------
01:02:46: Loading up D3D10 on NVIDIA GeForce GTX 570...
01:02:46: ------------------------------------------
01:02:46: Audio Format: 48000hz
01:02:46: Playback device Default
01:02:46: ------------------------------------------
01:02:46: Using desktop audio input: Speakers (Realtek High Definition Audio)
01:02:47: ------------------------------------------
01:02:47: Audio Encoding: AAC
01:02:47:     bitrate: 256
01:02:47: ------------------------------------------
01:02:47:     device: CY3014 USB, Analog 01 Capture,
01:02:47:     device id \\?\usb#vid_1164&pid_f531#5&3cc0&0&7#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\{6f814be9-9af6-43cf-9249-c0340100021f},
01:02:47:     chosen type: YUY2, usingFourCC: false, res: 1920x1080 - 1920x1080, frameIntervals: 166833-333667
01:02:47:     use buffering: false - 0, fourCC: 'YUY2'
01:02:47:     audio device: Disable,
01:02:47:     audio device id Disabled,
01:02:47: 
01:02:47: Using directshow input
01:02:47: Scene buffering time set to 700
01:02:47: Using custom x264 settings: "crf=16.5 keyint=60 min-keyint=25"
01:02:47: x264: VBV maxrate specified, but no bufsize, ignored
01:02:47: x264: NAL HRD parameters require VBV parameters
01:02:47: ------------------------------------------
01:02:47: Video Encoding: x264
01:02:47:     fps: 60
01:02:47:     width: 1920, height: 1080
01:02:47:     preset: veryfast
01:02:47:     profile: high
01:02:47:     keyint: 60
01:02:47:     CBR: yes
01:02:47:     CFR: yes
01:02:47:     max bitrate: 1000
01:02:47:     buffer size: 0
01:02:47: ------------------------------------------
01:02:47: MMDeviceAudioSource: Frequency for device 'Speakers (Realtek High Definition Audio)' is 384000, samples per sec is 48000
01:07:53: Total frames encoded: 18353, total frames duplicated: 14 (0.08%)
01:07:53: Total frames rendered: 18358, number of late frames: 2 (0.01%) (it's okay for some frames to be late)
01:07:54: 
01:07:54: Profiler time results:
01:07:54: 
01:07:54: ==============================================================
01:07:54: video thread frame - [100%] [avg time: 2.104 ms] [children: 76.9%] [unaccounted: 23.1%]
01:07:54: | scene->Preprocess - [73.7%] [avg time: 1.551 ms]
01:07:54: | GPU download and conversion - [3.18%] [avg time: 0.067 ms] [children: 2.19%] [unaccounted: 0.998%]
01:07:54: | | flush - [1.57%] [avg time: 0.033 ms]
01:07:54: | | CopyResource - [0.523%] [avg time: 0.011 ms]
01:07:54: | | conversion to 4:2:0 - [0.0951%] [avg time: 0.002 ms]
01:07:54: Convert444Threads - [100%] [avg time: 1.096 ms] [children: 99.2%] [unaccounted: 0.821%]
01:07:54: | Convert444toNV12 - [99.2%] [avg time: 1.087 ms]
01:07:54: encoder thread frame - [100%] [avg time: 1.534 ms]
01:07:54: ==============================================================
01:07:54: 
01:07:54: 
01:07:54: Profiler CPU results:
01:07:54: 
01:07:54: ==============================================================
01:07:54: video thread frame - [cpu time: avg 1.507 ms, total 27671.9 ms] [avg calls per frame: 1]
01:07:54: | scene->Preprocess - [cpu time: avg 1.114 ms, total 20453.1 ms] [avg calls per frame: 1]
01:07:54: | GPU download and conversion - [cpu time: avg 0.045 ms, total 843.75 ms] [avg calls per frame: 1]
01:07:54: | | flush - [cpu time: avg 0.021 ms, total 390.625 ms] [avg calls per frame: 1]
01:07:54: | | CopyResource - [cpu time: avg 0.005 ms, total 109.375 ms] [avg calls per frame: 1]
01:07:54: | | conversion to 4:2:0 - [cpu time: avg 0.003 ms, total 62.5 ms] [avg calls per frame: 1]
01:07:54: Convert444Threads - [cpu time: avg 1.003 ms, total 36750 ms] [avg calls per frame: 2]
01:07:54: | Convert444toNV12 - [cpu time: avg 1.003 ms, total 36734.4 ms] [avg calls per frame: 2]
01:07:54: encoder thread frame - [cpu time: avg 1.087 ms, total 19906.3 ms] [avg calls per frame: 1]
01:07:54: ==============================================================
01:07:54: 
01:07:54: =====Stream End: 2013-12-09, 01:07:54=================================================

 

[paibox]

First off, keep in mind that a 60 frame keyframe interval for a 60 FPS video can be detrimental to the final video output. Second, the reason OBS used less CPU when you ran the game on the capture computer is most likely because OBS couldn't encode at your specified frame rate (60) or the game couldn't output at an even 60 FPS, and lower frame rate when encoding (or a lower amount of unique frames) results in less CPU load.

However, I've been testing this a bunch this morning, and it seems that most media players under default conditions simply aren't able to decode all the frames fast enough to show them, or the video output method is inadequately fast to do so.

I did a few test recordings earlier, and 1080p60 encodings at a very high bit rate in general played back like absolute butt. If you are using VLC to check your recordings, I recommend going into preferences (Tools->Preferences) and then selecting the "Video" section of the settings, then setting the "Output" option to "Direct2D video output", as this seemed to result in the smallest amount of lost frames for me, and also the smoothest video playback.

80-90% CPU load when encoding actual 1080p60 source material is normal, 67% isn't.

 

[Sapiens]

I had CBR checked with a custom buffer of 0 which I believe achieves the same thing as what you're stating.

It does not. You set a vbv-bufsize of 0 with VBR to allow the encoder to use whatever bitrate is necessary to achieve the quality target you set with the crf param. CBR and crf are mutually exclusive.

If the capture card is connected to a PC, who's only purpose in life is to take streamed video from a Gaming PC through the capture card and encode it, wouldn't that be 10 times better than encoding on the same PC that you're playing the game on?

But the capture card itself doesn't do anything to reduce the CPU load. It plays an important role to be sure (gotta have some way to get the video over to the second PC) but it isn't doing any of the encoding. All of the work is still being done by the CPU in the second PC.

I also expected that log request to appear at some point

Based on the log there don't appear to have been any issues with encoding outside of what I mentioned above, so as paibox suggested something like a playback issue seems to be more likely at this point.

 

[Zero32]

I realized early on that the majority of video players were incapable of playing back the videos that I encode, but that if I were to upload them to a website, say YouTube, that they would playback smoothly 100% of the time. For that reason, I started using Windows Media Player Classic to preview what I had recorded because it "seems" to playback a 100% accurate representation of what I could expect to see if I upload the video.

Playing the video back in VLC or Standard Windows Media Player results in the stuttering effect I mentioned, but on a far larger scale (all over the video, not just in high motion scenes), whereas with WPC-HC (Windows Media Player Classic - Home Cinema) the video only stutters during high motion scenes, which is what I can see when watching the videos on YouTube as well. =(

Sapiens, I'm not sure what you're saying about the vbv-buffsize. When I encode using the settings I listed, the bitrate ranges freely from around 90kb/s (during pitch black scenes) to 82,000kb/s (fast motion scenes). This sounds like what you were describing.

One more thing is that I can take out the custom x264 setting of crf=16.5 which leaves keyint=60 min-keyint=25, check CBR mode and set it at 72,000kb/s and not experience the stuttering effect at all during playback, but this leads to large files... and re-encoding them later using MeGUI causes the quality to suffer because they were already encoded during capture. =\

 

[Sapiens]

I realized early on that the majority of video players were incapable of playing back the videos that I encode, but that if I were to upload them to a website, say YouTube, that they would playback smoothly 100% of the time.

Youtube actually doesn't support 60 FPS video (maybe with "Source" quality if you have access to that?) and tends to do a pretty bad job of transcoding down to 30 FPS, so if your goal is to upload there then you should probably be recording at, or re-encoding down to, 30 FPS anyway.

When I encode using the settings I listed, the bitrate ranges freely from around 90kb/s (during pitch black scenes) to 82,000kb/s (fast motion scenes). This sounds like what you were describing.

Interesting, maybe the CBR options are being ignored them. The whole point of using CBR is to output a video with a relatively constant bitrate, which is great for live streaming but really inefficient for local recordings. Why would you try to force CBR mode for a local recording, or when you've defined a crf value at the same time?

One more thing is that I can take out the custom x264 setting of crf=16.5 which leaves keyint=60 min-keyint=25, check CBR mode and set it at 72,000kb/s and not experience the stuttering effect at all during playback, but this leads to large files... and re-encoding them later using MeGUI causes the quality to suffer because they were already encoded during capture. =\

So now it's obviously it's a playback issue, yes? You shouldn't have any noticeable quality loss when you re-encode from a 72 Mbps file if you use decent settings in MeGUI like, say, the crf value from your original post.