Video Revision Reason 8/12

Street Legal Racing Redline has an issue where the game audio goes out of sync as you play it. I was poking around at the footage, trying to figure out exactly how it desyncs to find a way to keep the audio in sync. I uploaded the test resync audio video instead of the real video because the names where basically the same and I didn’t notice that I clicked the wrong one.

Video Revision Reason 7/27

It seems like it’s pretty frequent that I have reasons to have a revised version of a video, and it’s frustrating for both me and you when that happens. So I decided to make a log of why exactly it happens and what I do to stop it form occurring in the future.

On 7/27 a video for We Happy Few had an audio issue where roughly 8 minutes into the video the audio got desynced.

I check videos twice by hand before uploading,, and a third time after it’s live since usually I am waiting on YouTube to encode the video.

Why did I not notice this on the first check?

To maximize encoding speed my editor extracts the audio from the video, and edits that separate of the video file itself. I do this because I run my audio through a handful of VSTs which run slower than encoding the video itself because the VSTs aren’t able to utilize more than a single cpu core at a time.

The first video check is done using an audio track that was muxed into the video while recording using dxtory. This audio track is edited with the video, and is normally replaced at the last step with an audio track that includes the voiceover with VST affects and gameplay audio mixed in. So the video I checked over in stage one looked correct from start to finish.

The second check is a real quick check to make sure the audio muxed together properly so that there is both a voice and game audio in the video. I didn’t pay attention to how the audio synced because I never before had an audio sync issues that was not present in the first check.

Why did the error actually happen?

This happened because of a silent crash of ffmpeg while extracting the audio from a section of the video causing a roughly 2 minute audio clip run for a bit over a minute desyncing the audio by the difference of those two clips.

Previously, when extracting audio, all I did was check if ffmpeg gave any errors, if no errors where given the extracted audio was assumed to be extracted successfully. This worked for any time there was an issue with the video or audio track itself, but didn’t cover this specific situation where I had ffmpeg silently crash which had never happened before to me.

How am I going to stop this in the future?

About a week ago I upgraded the version of ffmpeg I used to a newer build, but have now rolled back to the old revision in case this silent crash was caused by the upgrade. In addition to this I added a check to make sure the output of ffmpeg when extracting the audio file is the expected length with precision to the thousandth (EDIT: Make that hundredth) of a second which should be enough for audio recorded at 96Khz. I also added a check when mixing the voice track, and the game audio track to make sure they are the same length.

Hopefully I don’t have to write posts like this often, but I just want to make sure you guys know that I too am frustrated by the frequency of version 2s of videos, and I am putting effort into making it happen less and less. My video editor recently has been going through a bunch of major revisions lately adding more and more fail safes for issues like this, but it’s hard to catch them all.

I noticed this issue about 15 minutes after the video went live, so my appologies to the about 500 or so of you who saw it before it was fixed.

Why Encoding For YouTube Sucks

Something I’ve been meaning to make a post about for a while, but have never really gotten around to doing until now.

First thing to explain.When you watch a YouTube video how you watch it determines how good the quality will be. For example if you watch a video on Google Chrome you will probably see a video encoded using the VP9 codec. If you watch a video on Mozilla Firefox  you will probably see a video encoded using the H.264 codec.

The VP9 codec is solid and works great, and I have no complaints about it. The H.264 codec on the other hand can be very troublesome.

If you upload a video that is too detailed the video will have  extremely inconsistent visuals. Too demonstrate this I used a 30 second clip from the video game BeamNG.drive.

I start off with a clip that is encoded in a lossless format that is in total 2.75GB. I then encode that lossless clip using ffmpeg using the crf 18 preset. This makes the video look nearly identical to the original clip, but it reduces the file size all the way down to 356MB. I then upload that video directly to YouTube. Once on YouTube some parts of the video will look fine, other parts will look significantly worse with the quality jumping all over the place around every 5 seconds.

Now for a comparison so you can see what I am on about. I found a frame where YouTube’s H.264 encode looks reasonable, and a frame where it looks ugly

A screenshot from the lossless encode

A screenshot from the crf18 encode

A screenshot from the H.264 encode by YouTube

A screenshot from the lossless encode

A screenshot from the crf 18 encode

A screenshot from the H.264 encode by YouTube

Watching a video that fluctuates in quality this much is not a pleasant experience, so what is the solution? Encode the video at a lower bitrate so YouTube’s encoder has less details to work with. So for this next example I encoded the video with an average bitrate of 12000kbps, and uploaded that to YouTube. And here is what it looks like after being encoded by YouTube.

As you can see above the good looking screenshot looks a bit worse, but the bad looking screenshot looks significantly better. And when actually watching the video the fluctuations in quality are minor enough where it’s usually not distracting from the video.

I did a lot of test running videos from crf  18 to crf 36 and bitrates from 5000kbps to 20000kbps (at 1000kbps intervals) trying to find the highest quality video I could upload without causing dramatic fluctuations in quality. My conclusion was that crf encoding didn’t work well because in scenes where little movement was happening bitrate encoding looked better while looking about equal in scenes with a lot of movement.

This number of course is only relevant for this specific video game, any other type of video I do usually gets a couple of test encodes at high qualities and I slowly tone it down until the quality looks consistent enough to be acceptable.

And an unfortunate side-affect of reducing the quality of the uploaded video is that the VP9 encoded video’s visuals start to suffer because there is too little details present in the uploaded video.

It’s a really tough balancing act that you just can’t win.

I should point out most videos probably won’t have this issue. This game in particular though does a really swell job of showing the worst of YouTube’s H.264 encoder.

An alternative solution I previously toyed around with was adding motion blur to the video in post which helped create more consistent visuals at higher bitrates, but it just didn’t look “right” when you were watching it. I might run that test again just to get viewer feedback though since that was entirely personal opinion. Maybe it would be more “cinematic” and others would like it. I have no idea.

Two videos discussed in this article can be viewed here.
crf 18 encode
12000kbps encode

Changelog
V2. Screenshots now work as expected.

I’m Making Mods!

I might be releasing some mods that add some older modded vehicles to the new vehicle selector.  Just some basic things that will make it easier to find the vehicle you want. It only takes a couple minutes to make them, and I just sort of make them as I need them.

WOO

WASSUP LOOK AT DEM SPECS BRA