Question / Help VBV in custom ffmpeg recording not working?

[HDL]

Here is an example of my syntax:

preset=ultrafast x264-params=crf=0:keyint=1:crf-max=51:vbv-maxrate=1M:vbv-bufsize=500

The extreme settings are just for testing, since crf 51 is very easy to notice. I'm just trying to get it working first, with no success. According to other posts I've read on the forum, the syntax should be correct, and my log file doesn't say any of them failed.

My system can handle crf 0 except for prolonged demanding scenes, at which point the memory usage goes up and my system crashes eventually. I'm trying to constrain the bitrate but so far it seems to be ignoring the vbv options entirely. Is my format wrong or is it a bug?

 

[Suslik V]

The mentioned settings has no sense for selected encoder and format.

If you need lossless quality - try simple output first.

 

[HDL]

It absolutely does. x264 has a capped crf mode using the vbv that allows you to prevent overloading the system, while preventing it from degrading the quality past a certain point. The eventual goal is to cap it at crf 15.

Simple mode does not record RGB, as the libx264rgb codec is unselectable.

 

[HDL]

I tested in ffmpeg directly and figured it out; here's the answer for anyone who might need this in the future.

It turns out the vbv is incompatible with crf 0 entirely. It only activates if you start with crf 1 or higher. Something like this would work correctly:

preset=ultrafast x264-params=crf=1:crf-max=15:vbv-maxrate=300000:vbv-bufsize=600000

The values will depend on what you need specifically and what you're trying to do, but functionally these settings work properly. Using crf 0 always disable vbv.

Edit: Just want to mention that, in the case of the CPU being the bottleneck (which happens for me with demanding games), you can use threads=N to limit how much CPU x264 is allowed to use. For me this completely prevents system crashes from memory exhaustion, as the encoder will instead opt to drop frames if it can't keep pace.

 

[Suslik V]

Why RGB? Just wonder.

Edit: simple output mode has special lossless encoder.
Edit 2: back to OBS v21.1.2 there lossless should work OK (at least in simple output mode).

 

[HDL]

I use RGB because that's what computers natively display. It's always best to keep recordings in the format the source device natively uses, unless you need compatibility (like for streaming) or really really need the disk space.

Simple mode does not record RGB. Lossless doesn't necessarily mean identical to the source, it just means that no generation loss occurs in the compression, but there may still be color conversions happening (which is what OBS is designed to do by default, since streaming services require it). Let me showcase the difference.

Source, this is from the game itself:

OBS defaults (NV12, rec 601, partial color range) lossless recording:

Simple output lossless recording with RGB selected in the advanced tab:

You can see that the latter two lose clarity and the color values are inaccurate, despite being "lossless." The color conversion ruins the image. If you record a proper lossless RGB video, it looks identical to the source image at the top. This is why I always use ffmpeg via command line, or OBS custom ffmpeg output for my videos.

 

[koala]

OBS is designed and optimized with the NV12 color format in mind, since OBS is a streaming client and NV12 is the color format all streaming services are using.
If you are not a professional movie producer who needs lossless for every frame to keep up quality at cutting and postprocessing, let go your idea of saving video lossless. Especially if you just record for archiving and later playback, and usage without much postprocessing. It's most easy if you just let it go and just use the default settings: color format NV12 and color range partial. Concentrate on an appropriate encoder quality preset (such as CQP or CRF and quality values around 15). You will see many problems you currently encounter will just vanish into thin air, including media players not playing back lossless footage correctly.

 

[HDL]

I've been recording RGB videos for years with no problems, but that was mostly for sources at lower resolutions. I've already figured out the solution to my VBV problem (and explained it for people who might use it), so I'm not sure what you're taking issue with here.

NV12 is a legacy, deprecated format that is only used for streaming out of requirement (companies like Twitch want to save money on bandwidth). There is literally 0 reason to willingly butcher your locally recorded videos if you have the hardware to get accurate capture and the disk space to accommodate it. It's not like people are going to transfer these videos to a camera that natively uses YUV. There is even less reason to tell someone to "let it go" just because you personally use different options. As far as I'm concerned, I'm just using OBS as a frontend for ffmpeg. The fact that its primary purpose is streaming is irrelevant.

 

[Suslik V]

v24 of OBS Studio has nasty bug in lossless mode - it applies 4:2:0 conversion as I see (it seems to be known issue).
In obs, the lossless - is literally without quality loss.