Question / Help Possibility to record without encoding in .avi?

[The Dog]

Hey everyone,

I hope this questions wasn't asked here in the forum yet (I couldn't find it) but is it possible to record (Yes i know with streaming it isn't possible) your desktop without encoding the video. My first idea was to change the container format to .avi and disable the encoder but that didn't work. In case whenever i disable the encoder the generated files are kind of broken because their filesize is just about 8KB.
The reason for this question is that I hope that it is possible to record without a huge CPU usage and do this job afterwards in DaVinvi Resolve. I know that OBS was created for streaming and so i wouldn't be disappointed if the program can't do so.

The Dog

 

[koala]

This will not work. Even if it were possible to record without encoding, the resulting files would be extraordinarily huge and the required hd speed to consistently write this over the whole recording time would be over the speed of any HD. Only faster SSDs would be able to write at this speed, but they are immediately full with such huge files, and writing with such a high speed also needs quite some CPU power, which your PC apparently doesn't have.

 

[The Dog]

Okay that seems logical but as far as i know there are some other programs which are able to record avi files without a high CPU usage. It's true the files are extremly big (one hour video more than 50GB) but it works.
The question why I am aksing this is that my PC have quite an average CPU (i5 4570) which is good enough for all the things Mr. Average wants to do but recording CPU intensive games with this CPU isn't really nice (encoding with veryfast needs about 20-25% of my CPU). So I came up with the idea that it might be possible to do the job afterwards while rendering the video so that there is more CPU power for the game while recording.

 

[koala]

Use a hardware encoder instead of x264. If you have a i5 4570, use the Quicksync hardware encoder. If you have a Nvidia GPU, you probably have the nvenc encoder, which is better than Quicksync. Hardware encoders have very low CPU demand. If you use one of these, use the CQP rate control with a CQP value of 15-25 (lower values mean higher quality), not CBR, so the quality is just as good as x264.

In case you have nvenc available, get the OBS Studio 23 release candidate test build: https://obsproject.com/forum/threads/obs-studio-23-0-release-candidate.100204/
It has total focus on lowest possible CPU usage with its new implementation of the usage of the nvenc encoder (use the nvenc encoder with "(new)" at the end).

 

[The Dog]

Thank you for your help. I just tested the Nvenc encoder in my OBS version and it worked kind of great. I know that there is the new Nvenc encoder in current versions. What are the advantages of the new Nvenc compared to the old one?

 

[Agamemnus]

Hey mate,

https://unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/

This compares x264, QuickSync, and in relation to your last question, NVENC accross 3 generations. Turing RTX 20 series is easily the best. You can find it on page 8 and 9, page 8 has Maxwell and Pascal NVENC, Page 9 has Turing.

Depending on bitrate starvation, or bitrate abundance, many codecs will either shine or fail. But Turing doesn't seem to vary so much, it just wins everywhere.

 

[koala]

The new nvenc implementation in the release candidate build of OBS I speak of is independent of GTX or RTX cards.
In the old implementation, OBS downloads the video data from GPU memory to CPU memory for encoding just like for any other encoder. Then it calls the encoder with the frame data. If the encoder happens to be the old nvenc, the video data is uploaded to GPU memory again, since the nvenc circuit works on the GPU.
The new implementation avoids the redundant double copy which consumes cpu resources and pcie-bus bandwidth.

 

[R1CH]

The "lossless" preset in simple recording mode will write utvideo to an AVI file, although you'll also need the codec installed in order for it to import into Premiere.

 

[Agamemnus]

The new nvenc implementation in the release candidate build of OBS I speak of is independent of GTX or RTX cards.
In the old implementation, OBS downloads the video data from GPU memory to CPU memory for encoding just like for any other encoder. Then it calls the encoder with the frame data. If the encoder happens to be the old nvenc, the video data is uploaded to GPU memory again, since the nvenc circuit works on the GPU.
The new implementation avoids the redundant double copy which consumes cpu resources and pcie-bus bandwidth.

That's just the software controls. Turing is barely affected by these changes, Pascal and Maxwell benefit from them more. Quicksync is better than Maxwell and Pascal NVENC in many circumstances, but it is never better than Turing, no matter the version of OBS.

 

[koala]

Turing is barely affected by these changes, Pascal and Maxwell benefit from them more.

Why? And in which regard?

 

[Agamemnus]

The hardware encoder itself is capable of doing specific things, and ONLY those specific things.

OBS tells the encoder library what it wants, then the library has methods of accessing the encoder to get it. The library which access NVENC, up to today, has only done it certain ways. Do it in OBS and you get the results in that link I posted according to the "hq" preset, which is just the name of an FFMPEG preset. However in FFMPEG you can use a "slow" preset which gives you more quality in the same bandwidth.

Turing is completely unaffected by this. The end file is bit-for-bit identical using the "hq" preset or the "slow" preset. It makes absolutely no difference. Maxwell and Pascal versions ARE affected by this preset change, and OBS does not access the "slow" preset unless you use custom FFMPEG output and specify the encoder options yourself (which you have do do through the recording tab, but you can still stream with it by outputting to URL, it's just complicated to setup).

Turing will happily encode 1440p video at above 80fps without breaking a sweat, EVEN WITH the copy-to-RAM method. If you aren't recording a video quality higher than that, then NVENC is just doing exactly the same thing but waiting less. Imagine you need to encode 1080p 60 times per second, and you can do it at over 100 times per second if you want, but you only get 60 each second to work on, you spend the rest of the time waiting. Then you get an upgrade to be able to do it 110 times per second. You still don't get more than 60 frames per second in the finished product. You still have to wait for the frames to process them, you're just now waiting more. That is Turing NVENC.

 

[koala]

Please don't make it too complicated. The new nvenc in the OBS release candidate is mainly about performance, and because of this I recommended it in this thread.
There are two new options in the new nvenc implementation that deal with quality (Look Ahead and Psycho Visual Tuning), but how much this affects quality, I don't know. For simplicity, I assume it doesn't affect quality at all. This thread is not the right place to discuss fine-tuning the quality of nvenc, it's about performance. Recording didn't work at all for the OP, and that's what the thread is about. He only tried to record lossless, because he thought this doesn't use much CPU. Not because he wanted a lossless video.

 

[Agamemnus]

"What are the advantages of the new Nvenc compared to the old one?"
That's the OP's last question before I answered. The answer to the question is that for Turing it doesn't matter, it beats everything, irrespective of the version of OBS. For other NVENC versions it does matter, it changes where they fall compared to x264.

I'm not intentionally making it complicated, I answered the question immediately before my response as basically as I could. It seemed like you were asking for more, I ran with it.

 

[The Dog]

Thanks for your help. I just watched a Video from EposVox on YouTube and he explained the diffrences very well. Now I use the new NVENC with a Bitrate of 50k and it works fine and the image quality is very well too.