FFmpeg 4.0

Published on 21 Apr 2018

I saw it on HNews late evening of 20th April. I could not contain my excitement as it bundles support for what I have been hoping for: libaom AV1 support. There have been some news dump lately on the latest (and greatest?) video codec, the AV1, which is being developed by the Alliance of Open Media.

On top of the support for libaom, there are a couple more improvements but I am not going to cover those here. Feel free to read the HNews link above to figure out more about this recent update.

So I was kind of excited to test the libaom support. Unfortunately, no static binary available yet (as of writing) and I do not want to spend time compiling and debugging. I had this thought to use a Docker or LXD container to keep the testing environment confined but again I do not want to spend too much time on that. Also because I have General Virology exam this coming Monday on 23rd April, so let’s spend time wisely.

Note: There are two FFmpeg Docker containers that I am aware of: one by Bruno Celeste (last updated 2 years ago) and another one by Julien Rottenberg (last updated 20 days ago). I might refer to their Dockerfile and create my Alpine-based FFmpeg container, assuming I do have time to work on this later.

Interestingly, the libaom support has been there in the Zeranoe FFmpeg build for quite a while. Based on a topic posted on Zeranoe forum dated 30th March 2018, running the libaom requires -strict -2 flag. Thus, our command would look like this:

$ ffmpeg.exe -i input_video.webm \
  -c:v libaom-av1 -strict -2 \
  output_video.mkv

Where -c:v flag defines the codec which is libaom-av1. All available codecs for FFmpeg can be queried with command ffmpeg -codecs. As of writing, both encoder and decoder for libaom are available. Note: I am using FFmpeg Zeranoe v3.4.2, not v4.0 because that’s not available yet.

The next question is: what about the encoding performance?

Note that as of writing the libaom can only take VP9/VP8 as the video input (.webm) and Vorbis/Opus as the video input (.ogg). If a video has its video track encoded with VP9 and audio track encoded with Opus, in theory that should work. However, when I tried encoding a video from VP9+Opus, I could not get FFmpeg to finish its encoding (more on this next time). So I went with video that just has a VP9-encoded video track.

The encoding performance is… well… terribly slow. The encoding speed was 0.003x on average. This means when we try to encode a VP9-encoded video that runs for 3:00 minutes (180 seconds), it would take 60,000 seconds or 1,000 minutes 16.7 hours to finish encoding. I am not sure if I did something wrong (which I think very likely), or something else that I could not think of.

That’s all for now. I am planning to pit some codecs against one another soon and publish their performance. To do that, I probably need to learn how to perform video quality metrics