Jump to content

Older CPU encode vs. NVENC video capture

da na

I would like to capture footage (From a StarTech DVI USB capture box and Blackmagic analog capture device) but I am not sure what the best way to do that would be. I use 1080/60, 'Large file size' preset in OBS and ~40000kbps bitrate. Yes, this is overkill. 

I could CPU encode with an i5-4590, this CPU should be powerful enough to handle high bitrate 1080/60. 
Or, I could try NVENC with a spare Quadro M2000 card in an LGA 775 system. I would need to install a USB 3 PCIe card since both capture devices require USB 3. I have not used NVENC very much on this card, but it is similar to a GTX 960 from my understanding so I assume it would do just fine. I would start with a Core 2 Duo but if required, could bump it up to a quad core.

Which would be the better solution? Both would be free to set up as I already have parts. I would prefer to use the i5 system simply because it is in a SFF case and has a quiet cooler, and thus could be easily put anywhere I need without interrupting recording. However, if the Quadro will produce much higher video quality or something I would obviously want to use that. Power consumption is of no concern, heat is not a huge problem, but noise I would like kept as low as possible.

Link to comment
Share on other sites

Link to post
Share on other sites

In general GPU encoding cannot compete with CPU encoding for video quality all other factors being the same as much as possible (even giving both encoders the same running time).

 

That being said modern GPU encoders are quite good. The new Intel AV1 GPU encoders can compete with x265 slow preset in some cases for quality. But this doesn't apply to you; the M2000 is quite an old card.

 

Outside of testing your own input footage side-by-side on CPU vs GPU tests and pixel peeping many frames, my recommendation would be to stick with CPU encoding as much as possible.

Link to comment
Share on other sites

Link to post
Share on other sites

Use the CRF setting with software encoder (x264) ... CRF is sort of like saving each frame of the video at some percentage of quality (like for example saving at JPG 95% quality). 

 

The codec starts from lossless (100% quality) and analyzes the frame optionally using a few previously encoded frames to determine what could be compressed and how much image quality would be lost, and as soon as the image quality level reaches that threshold you set, it stops trying to compress further.

 

With x264, a CRF between 2 and 5-6 is pretty much lossless, it's like 99% JPG quality, but you'd get very big files. Around 8-12 is bluray level quality, maybe even better, and around 18-22 is where you'd average around 15-25 mbps bitrate, like 10-15 GB movies.

I would recommend starting with CRF 10

 

CPU usage preset ultrafast, fast, medium, slow ... in CRF mode, this is just a tradeoff between how much cpu is used to compress a frame, and how much disk space the frame will be. A frame encoded at ultrafast will be same quality as the one encoded at medium or very slow, but faster presets mean more disk space.  Think of it like in ultrafast mode you can only use addition and substraction to calculate something, but in fast you could also use multiplication and in slow you could use square root. The slower the preset, the encoder can try to compress something through multiple methods and pick the one that results in less space, or it can use smarter ways to compress stuff resulting in less disk space.

With your CPU, you'll probably be fine with veryfast preset, if not working right, go with superfast.

 

If you're not capturing a game, the stuff in Advanced is very important. Set the color format properly and the color space.

The Startech DVI capture box may give you only RGB24 or YUV4:2:2  - x264 will convert whatever to YV12/NV12 but it's important to capture in the proper color format.

Color space ... if you're capturing under 1024x768, that's considered SD content, and the capture card or the device you use to play content may output using color space Rec 601 - that's the standard for SD content... and then you may want to add --color-prim [value]  at x264 options  (see 2nd picture below)

      --colorprim <string>    Specify color primaries ["undef"]
                                  - undef, bt709, bt470m, bt470bg, smpte170m,
                                    smpte240m, film, bt2020, smpte428,
                                    smpte431, smpte432

use smpte170m for NTSC SD content , BT470bg for PAL SD content

 

At resolutions above 1024x768  (ex 1280x720 or 1366x768  aka "hd ready") Rec. 709 color format is assumed

 

image.png.ac40306f01667ee9c0b8509987002cc0.png

 

image.png.2fa185cec8bdeb0388ce45fd4af2fb7e.png

 

image.png.66b5dc63afd96c510be1d4c269e93aa1.png

Link to comment
Share on other sites

Link to post
Share on other sites

ps. You could record with preset ultrafast , CRF 2  and audio uncompressed or flac and get 50-100 mbps bitrates for 1080p content and get practically lossless video, and then run the big file through Handbrake or other programs (MeGUI for example), to compress again with x264 CRF 15.. 20 , preset very slow, to get something high quality at a reasonable bitrate like 10-25 mbps , and audio keep flac or compress to opus 192 kbps or AAC 256 kbps or something like that.  At preset very slow, on your cpu it would probably run at 10-20fps so it could take 3-4 hours for 1 hour of video to recompress.

 

OR, if you have a video card with hardware AV1 encoder (or HEVC), use that to compress to AV1 or HEVC which can retain more quality in same bitrate compared to h264 format .

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×