Help Configuring OBS Recording to Match Specific Video Parameters

[muphase4378290]

Hi everyone,

I'm trying to configure OBS to record a video with settings as close as possible to a reference file I received. Below are the specifications of the original video:
I'm Using OBS 30.0.1, on Macbook Pro 2017, 2,8Ghz I7 Quad-Core, Radeon Pro 555 2Go & Intel HD 630 1536Mo, 16Go 2133Mhz LPDDR3, OSX Ventura 13.6.9

General:

• Format: MPEG-4 (Base Media)
• Codec ID: isom (isom/iso2/avc1/mp41)
• File size: 95.0 GiB
• Overall bit rate mode: constant
• Duration: 4 hours 30 minutes
• Overall bit rate: 50.0 Mb/s
• Frame rate: 25.000 FPS
• Writing application: Lavf58.29.100

Video:

• Format: AVC (Advanced Video Codec)
• Format profile: Constrained Baseline@L4.1
• CABAC: No
• Reference frames: 1 frame
• Codec ID: avc1
• Duration: 4 hours 30 minutes
• Bit rate: 50.0 Mb/s
• Resolution: 1920x1080 (16:9)
• Frame rate mode: Constant
• Frame rate: 25.000 FPS
• Color space: YUV, Chroma subsampling: 4:2:0, Bit depth: 8-bit
• Scan type: Progressive
• Encoding settings: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=1 psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=12 lookahead_threads=2 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc_lookahead=0 rc=cbr mbtree=0 bitrate=50000 ratetol=1.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=50000 vbv_bufsize=50000 nal_hrd=none filler=1 ip_ratio=1.40 aq=0

Audio:

• Format: AAC LC
• Bit rate mode: Constant
• Bit rate: 320 kb/s (Track 1)
• Channels: 2 (Stereo)
• Sampling rate: 48.0 kHz
• Compression mode: Lossy

I have tried setting up OBS with a Custom Recording Output using x264 and specifying the parameters, but I am unsure if I am matching all the necessary settings correctly. In OBS logs file, the specific parameters "failed to set".

My questions:​

1. What is the best way to configure OBS settings to match these parameters as closely as possible?
2. Are there specific x264 encoding settings I should manually enter in OBS?
3. Is it possible to force constant bitrate (CBR) and disable variable bitrate (VBR) in OBS? In my attempt, log said's: "Overall bit rate mode: variable" event if i activate "CBR".
4. Should I configure stream output and use same encoder in record, or create a specific record output for this setup? (i dont stream, only record)

Any guidance would be greatly appreciated! Thanks in advance!

 

[AaronD]

Don't know about the rest of it, but:

Is it possible to force constant bitrate (CBR) and disable variable bitrate (VBR) in OBS? In my attempt, log said's: "Overall bit rate mode: variable" event if i activate "CBR".

At least one encoder (FFmpeg H.264) doesn't actually have a constant bit rate. It has a setting for it, but the description suggests (to me at least) an internal feedback mechanism with continuous adjustment of the quality setting, so that the core functionality that is hard-coded for constant-quality variable-rate, ends up producing the desired bit rate on average.

Encode/H.264 – FFmpeg

trac.ffmpeg.org

Depending on where the message actually comes from in the logfile, that might be what's happening here.

Should I configure stream output and use same encoder in record, or create a specific record output for this setup? (i dont stream, only record)

If you only ever do one of them and never the other, then it doesn't matter.

Using the same encoder forces both bitstreams to be identical, because the content is encoded once according to the streaming settings, and then that result is also dumped to a file. That can be useful if you only have one encoder to start with, and still need to do both, or if you want an *exact* record of what the stream was (or should have been).

But to do it well, each destination needs different settings, and thus two separate and simultaneous encoders (if you're doing both):

• Streaming has a limited bitrate, so you use a constant bitrate to take up most or all of that, and let it adjust the quality to have the best possible at that rate in each moment. Static parts of the image will quickly become sharp, while fast and detailed motion will be blurry.
• Recording technically has a similar limit (hard drive speed), but it's so high that it's practically out of the way. So you set it for constant quality, somewhat like choosing what reel of film to shoot a movie on. Then the bitrate is whatever it needs to be at each moment to describe all of what's happening then, with that amount of visual accuracy. The sum total of all those descriptions, is the resulting file size.

If you can use multiple encoders, and you want to leave the possibility open to stream, then I'd use the Recording settings and keep the Streaming settings available for that purpose. Otherwise, it doesn't really matter.

 

[muphase4378290]

Thank you, AaronD, for your detailed explanation!

I successfully configured my recording settings. I decided to keep the "Streaming" encoder available and use the dedicated "Recording" encoder for my setup.

Regarding the x264 options, I disabled both the "Profile" and "Tuning" settings, as they were overriding my manual parameters.

Thanks to this website: http://www.chaneru.com/Roku/HLS/X264_Settings.htm, I was able to understand the effects of different x264 options.

Additionally, using this reference: https://dev.beandog.org/x264_preset_reference.html, I found that the "ultrafast" preset already applied most of my desired settings. In the end, I only had to manually force three parameters, which were no longer overridden after disabling "Profile" and "Tuning".

Again, I really appreciate your help!

 

[AaronD]

...I found that the "ultrafast" preset already applied most of my desired settings.

In that case, you can stand to be a lot more efficient in terms of quality vs. bitrate. The slower presets call for more work to figure out what's actually important and allocate more of the available bits to that, instead of describing everything equally.

Is there a reason to match those exact settings?

 

[muphase4378290]

Yes, that’s correct. My client requires this settings for archival purposes and wants to minimize compression as much as possible.

 

[AaronD]

My client requires this settings for archival purposes and wants to minimize compression as much as possible.

I don't think your client understands compression, and is misusing that term.

If you want to minimize loss of detail, then you'd use the "Lossless" setting in Simple mode, and be ready for HUGE files.
If you want smaller files than that and still have them look the same for *most* uses (tradeoff...), then you'd use the "Indistinguishable" setting.

If you want something specific, like squeezing the very last bit that you can out of an oddly-limited system or connection (*), THEN you'd play with the custom settings.

If your client is a bureaucrat who knows and cares nothing about anything except paperwork...then this thread can make sense as-is.

---

(*)
Maybe a custom player or something like that? I used to be more enamored with that idea when I was younger. I would know *exactly* how it works and how to make it sing, and I could make it do whatever I wanted it to do, without being limited to what someone else thought was mass-marketable. But it was also incompatible with the rest of the world.

I've since seen the value in using existing standards and just-buying things (or getting them for free, as the case may be) that already follow those standards (not everything does: watch out for vendor lock-in!)...and then possibly tacking on a small additional custom thing to fill in the small amount that it still doesn't do.

 

[Lawrence_SoCal]

What Aaron said

and beware, Lossless video trades less CPU work (compression) for a LOT higher bitrate, which will push other hardware resource boundaries. And yes, there is compression, but that is essentially required on modern systems... and plenty of compression is visually lossless (ie yes compression, and takes some CPU to calculate encoding (compression) and process (expand) during payback, but is visually indistinguishable from lossless (uncompressed source video)... Then, with higher levels of compression (ex. for reasonable use of Internet) we get well into high compression and visually noticeable. but lots of variables in-between

- an almost 8 yr old laptop is NOT the right computer for heavy-duty real-time video work. You will run into thermal limits (impacting performance as well) if not careful.

And, I get using H.264 (avc1) as it is an old, well-understood and relatively open standard, but also takes more bitrate for the same quality as newer codecs. H.265 has some well-known licensing issues (which may or may not apply to customer org). And then there is the new AV1 codec, which requires new GPUs for encoding offload support.

1080p25 H.264 at 50.0 Mb/s seems like real overkill, most likely (depends on content). Most folks would be really hard pressed to tell the difference (non-high motion content) in the video at 1/2 bitrate... but if they are ok with excessive disk space...

I don't know on an old Intel Mac system, if using x264 (which on Windows/Linux side) means using CPU, not GPU offload, for video encoding. So question is encoding abilities of AMD Radeon vs Intel QuickSync (not my area, I don't know answer, and I'm guessing answer depends on specifics)