WhyBeAre

WhyBeBlogging

Monthly Archives: July 2016

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.