Video transcoding with FFmpeg

Using the FFmpeg command line to convert MP4, OGV, and WebM video.

This quick guide goes through some of the details on how we convert some video using FFmpeg. Video conversion is really important for those who are hosting their own files and not relying on a third party site such as YouTube or Vimeo because you are looking for the most compatible video standards that offer the best quality at the lowest bandwidth so that no only your server is happy but the users that visit your site. FFmpeg is awesome in respects that since it’s open-source it’s a binary that can be compiled on a remote server that you own and begin converting videos on the spot if necessary and if you have the CPU power to do it. You could even run FFmpeg on a Raspberry Pi if you wanted to wait a few years for the results!

The real drawback is FFMpeg is pure command line with no GUI which may scare some people away. We have other blog articles talking about GUI video conversion later on for those who are interest.

Making videos via command line / FFmpeg.

All of the examples given below are strictly ones which worked out well for me and was discovered through going through the FFmpegs documentation on their website.

Prepping FFMpeg onto your linux box.

sudo apt-get install ffmpeg libav-tools

This is the command that we passed to get it working on our raspberry Pi. It should also work with many linux environments that use the apt command such as debian.

Windows users can simply go to the FFMpeg site and download the stock binaries. We will be avoiding any self-compiling here out of simplicity.

Since we do not own a mac we are unable to provide instructions as to what to do on on OSX.

Test video download.

For our test video we shall be using something from our own site which is the Ukidig-HD.mp4 file which was recorded in dual-pass 25-35mb stream giving the maximum quality. This file is rather large at 290+ megs in size. You are welcome to download and follow along with this guide if you wish.

Making an MP4 file for web streaming.

ffmpeg -i Ukidig-HD.mp4 -c:v libx264 -profile:v high -preset slow -b:v 1500k -maxrate 2500k -bufsize 5000k -threads 0 -codec:a aac -b:a 128k Ukidig.mp4

The flag “-i” specifies the input file which in this exampled I used my high quality MP4 files of Ukidig. The “-c:v libx264” specifies that we want to make a .h264 compliant video file. “-profile:v high” and “-preset slow” ensure to get the best quality image which means it may take some time depending on the processor core that you are using. “-b:v 1500k” sets our variable bit-rate to 1500kbs or 1.5M for general streaming on the web. “-maxrate 2500k” acts as a throttle is case there is a lot of action on the screen. “-bufsize 5000k” is based off of maxrate 2x and typically is used for streaming media such as gaming. But in WordPress this is helpful too as it gives us a minimum two second buffer in the event of latency or lag. ” -threads 0″ is to use all of the processor cores in a system, you can set this however you want. “-codec:a aac” is our audio codec. Many people will demand libfdk_aac but due to licensing problems the only way you can get that is by compiling ffmpeg yourself. The default AAC codec is really good and works well with the h264 codec. “-b:a 128k” The bit-rate of the audio. For voice and narration you can set it down to 64k or 96k to save to space. But since this has music we keep it higher at 128k.

Phew! That was a lot of crap going on! But that is unfortunately the nature of MP4 and compressing it down to something smaller for web broadcast!

2-pass encoding of MP4.

2-padd encoding tends to give better quality renders of your video but may also increase the size of your file by approximately 10-20 percent. Here’s how that is done.

In windows:
ffmpeg -i Ukidig-HD.mp4 -c:v libx264 -profile:v high -preset slow -b:v 1500k -maxrate 2500k -bufsize 5000k -threads 0 -pass 1 -an -f mp4 temp.tmp ffmpeg -i Ukidig-HP.mp4 -c:v libx264 -profile:v high -preset slow -b:v 1500k -maxrate 2500k -bufsize 5000k -threads 0 -pass 2 -codec:a aac -b:a 128k -f mp4 Ukidig.mp4 del temp.tmp

Since you can’t pipe to /dev/null in windows, we simply let it make a temp file that will be deleted later.

In linux:
ffmpeg -i Ukidig-HD.mp4 -c:v libx264 -profile:v high -preset slow -b:v 1500k -maxrate 2500k -bufsize 5000k -threads 0 -pass 1 -an -f mp4 /dev/null && \ ffmpeg -i Ukidig-HD.mp4 -c:v libx264 -profile:v high -preset slow -b:v 1500k -maxrate 2500k -bufsize 5000k -threads 0 -pass 2 -codec:a aac -b:a 128k -f mp4 Ukidig.mp4

Yes, you are passing the command twice. The first pass generates a ffmpeg2pass-0.log file that FFmpeg then uses during its second pass to determine how to best optimize the mp4 file.

S, does it really matter? I mean, an encoder is an encoder right?

Initially we thought that way. Until we decided to re-encode one of our old videos. The XBCD V2 tutorial to be exact. Upon stopping both videos with VLC on 00:15 and taking a snap shot of my web-page at 1,500kbs or 1.5M. The constrast was startling. Even with doing a single pass render versus a 2-pass render in premiere it was still clearer. To add insult to injury. the Premiere file was 75.4Megs in size. the FFmpeg was 67.9Megs in size. This changes the way I encode things for my website and will be going through all of my master files to re-encode them for better-faster quality.

Making Webm files with FFMpeg.

ffmpeg -i Ukidig-HD.mp4 -c:v libvpx-vp9 -b:v 1000k -c:a libvorbis -b:a 96k -threads 0 Ukidig.webm

The flag “-i” specifies the input file which in this exampled I used my high quality MP4 files of Ukidig. The “-c:v libvpx-vp9” represents the video codec we will be using. Understand that you will need a very new version of FFMpeg to use the VP9 Library. Older FFmpeg that are in Debian distros will only have VP8 which is “-c:v libvpx.” We then specify a variable bit-rate of 1000k or 1M with “-b:v 1000K” which works very well when doing desktop based tutorials. For gaming or high action at 1080p you may want to increase this value to 2000k or more. Finally, the audio is compressed in vorbis which is traditional for WebM files with “-c:a libvorbis.” Bit-rate for the audio is set for 96k “-b:a 96k” as vorbis/ogg audio.

For more information check out the VP8 and VP9 documentation.

There’s also better documentation on the WebM project Wiki on how to use FFMpeg and WebM.

Making OGV files with FFMpeg.

ffmpeg -i Ukidig-HD.mp4 -c:v libtheora -b:v 4000k -c:a libvorbis -b:a 96k -threads 0 Ukidig.ogv

This is not the usual way you’re supposed to pass the command to make an OGV file! We’re specifying bit-rate with “-b:v 4000k” for 4000kbs transfer giving us a predictable file size for our blog. Ogg-theora by design uses scale levels of compression versus bit-rate. If you are not careful and specify a bit-rate too low such as avconv’s default 200k. You will receive an unwatchable ogv file with frame skipping especially at 1080p.

Audio is also limited to a 96k stream “-b:a 96k” because in our humble opinion ogg audio tends to handle a lot nicer then mp3.

A more civilized way of making an ogv file is as follows:

ffmpeg -i Ukidig-HD.mp4 -codec:v libtheora -qscale:v 5 -codec:a libvorbis -qscale:a 3 Ukidig.ogv

By using “-qscale:v 5” and “-qscale:a 3” of OGV ensures that the video will be compressed on a more exacting measure of quality over compression. However doing it this way may lead to some unpredictable file sizes especially when working with large resolution files like 1080p. Using a video qscale of 5 is even a little low for 1080p@60fps but it keeps the bandwidth in check on my site when showing something high action. Also, the percentage of users falling all the way back to OGV is incredibly low which is why we aren’t overly concerned about the quality. If you specify a qscale level. FFmpeg will then ignore variable bit-rate commands “-b:v” you pass to it in favor of scale settings.

Desktop tutorial settings.
ffmpeg -i Ukidig-HD.mp4 -r 30 -s 1280x720 -codec:v libtheora -qscale:v 5 -codec:a libvorbis -qscale:a 3 Ukidig.ogv

When encoding desktop videos such as the many tutorials on my site. We found it to be a lot better to simple reduce the resolution with “-s 1280×720” to bring it down to 720p. Also drop the frame rate down to 30fps with “-r 30” in order to half the framerate to keep the size low. Although a lot of the videos were shot at 1080p the desktop becomes a lot more readable and the size of the OGV becomes something that is easier to handle on this site versus fighting with a blocky 1080p OGV file.

For more information check out the OGV documentation.

Related Blogs:

Continue on to see how these video files are implimented into WordPress.

A quick mod to make WordPress choose WebM files first for browsers which can support it.



Leave a Comment to the Void