Articles | 2018 OBS-based Video Pipeline

This article will detail the proposed OBS pipeline for fifth-generation LP productions using OBS. This is made possible thanks to the research and source code modifications of UntamedLoli. It is expected you've read the previous articles on this subject, since they contain technical details relevant to this article I won't be repeating.

Premise

After research into chroma subsampling, the discovery of fraps using the 420 setting and thus notable damaging video media, plus the other limitations of the software, prompted HKS to research resolutions for the long-standing issues surrounding Open Broadcasting Software (OBS).

Fraps is an ancient beast, and how it works is very dirty and crude, but it does work. When virtually every single program I tested during my early console recordings desynced audio from vegas to audition 1.5 to CS5, fraps'ing a window produced 100% synced results. For years, fraps has produced synced audio and stable video streams from any source it can hook and has never broken recordings except when using the lossless RGB setting or from unrelated interruptions of the recording such as colossal performance problems or being forcibly alt-tabbed out. That steel-clad reliability has kept Fraps not simply relevant but leading video capture software all the way from its inception to 2018. Simply put, there has been no competition for the software except in desktop recording and presentations of that nature, such as my EDU series, which mandated extremely performance intensive and buggy software like Camtasia.

Since OBS' inception it was widely hoped it would finally outclass fraps. Critical features started to show up in the program, including multiple audio stream recordings, but at every turn OBS corrupted my audio, produced bugs, destroyed performance, and produced badly compressed and inaccurate files.

During HKS' research into the program's source code, he found the alleged 444 subsampling support from OBS was bugged by what appeared to be a lazy copypaste of some rescaling behavior from another part of the colorspace functions. Disabling this fixes the creeping colors observed ever since 2015 - a massive bug that rendered OBS incapable of producing high-quality video. Between this and careful tweaking of what few options were available, HKS managed to produce a profile and build for OBS that can quite possibly replace Fraps for many recording projects.

These are the major bulletpoints for using OBS over Fraps.

Pros -

- Multiple audio streams means no longer having to edit the whole thing at once. Easier troubleshooting volumes and things like fan noise or whatever, if necessary.

- 1:1 picture with source. Objectively superior picture quality to Fraps despite being compressed more heavily (CRF 11 in tests).

- Resilient to tabbing - no longer results in the software/game crashing immediately when I click offscreen. This is important since most games don't support dual monitors.

- Dramatically reduced io load and disk usage.

- Can hook some things that fraps cannot (such as Vulkan-based windows).

- Need to test how well OBS handles performance hits and how easily it can drop frames, but currently it reports a mere 0.3% loss average in the Doom 2016 recording.

- Source access. This pipeline is made possible only by HKS' ability to modify the program's freely available source.

Cons -

- Marginally higher CPU usage than fraps in my tests (Scales to CRF usage, tested at CRF 11). Notably, this cpu usage is consistent and doesn't change much depending on motion. Overall, the performance impact is more consistent and less significant than fraps, especially when starting recording (where fraps causes massive hits). This is a small caveat in the grand scheme, given I am running a 2009 i7 920 without overclocking.

- Has great difficulty hooking some applications reliably.

- Resulting files cannot be processed in Vegas and similar software - fraps must still be used as a quick-reach alternative, or an alternative profile with inaccurate colors set up beforehand.

- Doesn't support high-quality audio. You're stuck with 320 CBR coreAAC until HKS or someone else figures out how to make it support PCM or something similar. The quality loss is not enormous, but it is less than ideal, and the files take forever to open in processing software.

- Reliability is not time-tested. OBS has historic issues with corrupting audio, stopping recording without warning, and otherwise having massive and unreported issues. These may or may not have been related to the Xonar D2 and its legendary feature list of insane problems, so OBS needs thorough testing to be confident in it still.

- Development for OBS is needlepointed on low-quality streaming, and given the lack of attention to the i444 colorspace despite the ease of fixing it and the lack of support for high quality audio, both developer attention and demand for it seems non-existent.  Further pursuit of features in the program will require either somehow contacting the developers and convincing them to do it for an individual or manipulating the source ourselves.

Introduction

We'll be using OBS to capture the source recordings for our production. To ensure we have both acceptable performance and the 1:1 colorspace, we'll need a version of OBS compiled with the changes aforementioned. I may post or otherwise direct to that version in the future. I'll break down some of the most major settings for the program.

Recording Format: MKV -- We use MKV as opposed to mp4 because MKV is corruption resilient. If something happens to the recording, such as a power outage, MKV will still give us a functional file while mp4 will not. It's possible the mp4 can still be recovered in such an instance, but to save ourselves headaches we'll simply use MKV.

Audio Tracks -- Ensuring we have our two audio tracks enabled for the resulting file.

Rate Control: CRF -- The other options annihilate quality. We'll be using CRF. 12 produces 1:1 results but to be 100% sure I am using 11. The lower the setting, and thus higher quality, the greater the CPU usage. 0 is preferable, but my system is too old. OBS averages 30% cpu with this setting.

CPU Usage Preset -- This is an extremely important setting because it's actually controlling a lot of x264 configurations. We must use Ultrafast to disable features like Motion Estimation which make OBS use far too much CPU and ruin our source video accuracy.

x264 Options  -- Ensuring we are using the proper colorspace and reporting it.

The Advanced tab is pretty self-explanatory. We're configuring the color settings to use PC colorspaces and not something intended for an analog television signal in the 80's. i444 is what's bugged in the current public version of OBS. The bug causes certain colors, especially reds, to displace to the right. It pretty much destroys the image.

OBS has a habit of not actually setting its priority to "high", so we may need to do that in Process Explorer before we record. This is just so some other application can't fuck with our recording.

I've seen an alarming number of posts on the internet having no idea what these configurations do, so here's a quick glance at my audio settings. The various Captures for audio refer to either my mic interface or windows audio. No processing is necessary, since we'd just add needless CPU overhead for something we can do in post with far greater granulity than in OBS. The tracks seen in the Advanced Audio Properties refer to the same tracks we saw in the recording options.

It is important to note that OBS captures audio very differently than fraps. I'm not sure why, but the mic, despite being 100%, is usually half the volume of fraps. It also produces less static, and doesn't peak. I presume OBS has some hidden processing going on. Nonetheless, splitting the game and mic audio allows us to post the mic in ways we can't normally do with fraps, so the net result is still cleaner than before.

We don't want to have any more than one video Capture up at once, even when hidden, because OBS is apparently very much incapable of actually disabling those hidden captures and they can cause hidden conflicts. I haven't confirmed it myself, but I've read it enough times to ensure the scene setup is as minimalist as possible.

Avisynth & FFmpeg

As explained in the 2018 article, we'll be using FFmpeg for this. FFmpeg has a new task with the OBS setup, which is to pull our second audio channel out of the source videos. This is normally a simple process, but since each sitting of the game usually consists of 5 or more actual video files, we stand to be manually exporting and merging over a dozen files per segment of video. This is absurd and wasteful, so we need a way to pull the channels out and merge them.

This is actually a bit of a problem, because avisynth can't export a multi-stream video. We'll need to have two avisynth files, each one referring to a separate channel in the file. Since we're just using two channels, we simply change one integer for each file and that's it. We'll also need to use FFmpegSource2 for this (abbreviated to FFMS2), especially since MKV is our source container.

LoadPlugin("C:\Program Files (x86)\AviSynth 2.5\plugins\x86\ffms2.dll")
FFMS2("X:\mantits\doom-seg2\2018-07-06 22-39-37.mkv", atrack = 1)++FFMS2("X:\mantits\doomseg2\2018-07-07 00-10-55.mkv", atrack = 1)++FFMS2("X:\mantits\doom-seg2\2018-07-07 12-13-32.mkv", atrack = 1)

The second AVS file will simply change "atrack = 1" to "2" and that's it.

The template for Avisynth Batch Scripter to make these files is this.

++FFMS2("%PATH%\%CLIP%.%EXT%", atrack = 1)

You may need to download the ffms2 plugin off of google for it to work. 

For the audio, we use a .bat file that pulls the files and dumps them as PCM24 .wav's for us to process as we see fit.

ffmpeg -i "C:\anonh.avs" -c:a:1 pcm_s24le "H:\CURRENTVIDEO_stream1.wav"
ffmpeg -i "C:\anonh2.avs" -c:a:1 pcm_s24le "H:\CURRENTVIDEO_stream2.wav"
pause

And the rest is pretty self-explanatory.