Random thoughts
This page contains the latest entries thave I've published in my personal weblog. It discusses random bits related to my life, software development, my studies and such. The RSS for this feed is available from http://blogs.gnome.org/, as is the complete history.
Microsoft Visual Studio support in FFmpeg and Libav
An often-requested feature for FFmpeg is to compile it using Microsoft Visual Studio’s C compiler (MSVC). The default (quite arrogant) answer used to be that this is not possible, because the godly FFmpeg code is too good for MSVC. Usually this will be followed by some list of C language features/extensions that GCC supports, but MSVC doesn’t (e.g. compound literals, designated initializers, GCC-style inline assembly). There are complete patches and forks related to this one single feature.
Reality is, many of these C language features are cosmetic extensions introduced in C99 that are trivially emulated using classic C89 syntax. Consider designated initializers:
struct {
int a, b;
} var = { .b = 1, };
This can be trivially emulated in C89 by using the following syntax:
struct {
int a, b;
} var = { 0, 1 };
For unions, you can change the initialization (as long as the size of the first field is large enough to hold the contents of any other field in the union) to do a binary translation of the initialized field type to the first field type:
union {
unsigned int a;
float b;
} var = { .b = 1.0, };
becomes:
union {
unsigned int a;
float b;
} var = { 0x3f800000, };
Here, 0x3f800000 is the binary representation of the floating point number 1.0. If the value to be converted is not static, the assignment can simply become a statement on its own:
union {
unsigned int a;
float b;
} var;
var.b = 1.0;
Other C99 language features (e.g. compound literals) can be translated in a similar manner:
struct {
int *list;
} var = { (int *) { 0, 1 } };
becomes:
int *list = { 0, 1 };
struct {
int *list;
} var = { list };
Two other Libav developers (Derek Buitenhuis and Martin Storsjo) and I wrote a conversion tool that automatically translates these C99 language features to C89-compatible equivalents. With this tool, the FFmpeg and Libav source trees can be translated and subsequently compiled with MSVC. A wrapper is provided so that you can tell the FFmpeg build script to use that as compiler. The wrapper will then (internally) call the conversion utility to convert the source file from C99 to C89, and then it calls the MSVC build tools to compile the resulting “C89′ified source file”. In the end, this effectively means FFmpeg and Libav can be compiled with MSVC, and the resulting binaries are capable of decoding all media types covered by the test suite (32bit, 64bit) and can be debugged using the Visual Studio debugger.
For the adventurous, here’s a quick guide (this is being added to the official Windows build documentation as-we-speak):
Requirements:
- Microsoft Visual Studio 2010 or above (2008 may work, but is untested; 2005 won’t work);
- msys (part of mingw or mingw-64);
- yasm;
- zlib, compiled with MSVC;
- a recent version (e.g. current git master) of Libav or FFmpeg.
Build instructions:
- from the Start menu, open a “Visual Studio Command Prompt” for whatever version of Visual Studio you want to use to compile FFmpeg/Libav;
- from this DOS shell, open a msys shell;
- first-time-only – build c99-to-c89 (this may be tricky for beginners):
- you’ll need clang, compiled with MSVC, for this step;
- check out the c99-to-c89 repository;
- compile it with clang (this probably requires some manual Makefile hackery; good luck!);
- at some point in the near future, we will provide pre-compiled static binaries to make this easier (then, you won’t need clang anymore);
- get the C99 header file inttypes.h from code.google.com and place it in the root folder of your source tree;
- use the configure option “–toolchain=msvc” to tell it to use the MSVC tools (rather than the default mingw tools) to compile FFmpeg/Libav. Ensure that the c99-to-c89 conversion tools (c99wrap.exe and c99conv.exe, generated two steps up) are in your $PATH;
- now, “make” will generate the libraries and binaries for you.
If you want to run tests (“fate”), use the “–samples=/path/to/dir” configure option to tell it where the test suite files are located. You need bc.exe (not included in default msys install) in your $PATH to run the testsuite.
It’s probably possible to generate Visual Studio solutions (.sln files) to import this project in the actual Visual Studio user interface (e.g. libvpx does that) so you no longer need the msys shell for compilation (just for configure). Although we haven’t done that yet, we’re very interested in such a feature.
(Posted at Thu, 27 Sep 2012 20:48:40 +0000 - Comments)
Time for something new
In the beginning of December, Frederik was born. He’s growing up nicely.

At the end of December, I succesfully defended my PhD thesis (see earlier post) and was awarded a PhD for my research titled “Notch signaling in forebrain neurogenesis”. In January, the PhD was officially awarded.
So as my family expands and needs a bigger house, and my old way-to-spend-the-day came to an end, it was time for something new. Earlier this week, I started a new job as engineer at the big G. Rumor has it that I’ll be working on something related to video.
(Posted at Thu, 31 Mar 2011 04:25:30 +0000 - Comments)
Meet Frederik
The latest addition to our little sprouting family: Frederik Jie Bultje. Born December 12th, 2010 in New York.
(Posted at Mon, 13 Dec 2010 00:25:26 +0000 - Comments)
The world’s fastest VP8 decoder: FFmpeg

Performance chart for FFmpeg's VP8 decoder vs. libvpx
Jason does a great job explaining what we did and how we did it.
(Posted at Fri, 23 Jul 2010 23:07:39 +0000 - Comments)
Google’s VP8 video codec
Now that the hype is over, let’s talk the real deal. How good is Google’s VP8 video codec? Since “multiple independent implementations help a standard mature quicker and become more useful to its users”, me and others (David for the decoder core and PPC optimizations, Jason for x86 optimizations) decided that we should implement a native VP8 decoder in FFmpeg. This has several advantages from other approaches (e.g. linking to libvpx, which is Google’s decoder library for VP8):
- we can share code (and more importantly: optimizations) between FFmpeg’s VP8 decoder and decoders for previous versions of the VPx codec series (e.g. the entropy coder is highly similar compared to VP5/6). Thus, your phone’s future media player will be smaller and faster.
- since H.264 (the current industry standard video codec) and VP8 are highly similar, we can share code (and more importantly: optimizations) between FFmpeg’s H.264 and VP8 decoders (e.g. intra prediction). Thus, again, your desktop computer’s future media player will be smaller and faster.
- Since FFmpeg’s native VP3/Theora and Vorbis decoders (these are video/audio codecs praised by free software advocates) already perform better than the ones provided by Xiph (libvorbis/libtheora), it is highly likely that our native VP8 decoder will (once properly optimized) also perform better than Google’s libvpx. The pattern here is that since each libXYZ has to reinvent its own wheel, they’ll always fall short of reaching the top. FFmpeg comes closer simply because our existing wheels are like what you’d want on your next sports car.
- Making a video decoder is fun!
In short, we wrote a video decoder that heavily reuses existing components in FFmpeg, leading to a vp8.c file that is a mere 1400 lines of code (including whitespace, comments and headers) and another 450 for the DSP functions (the actual math backend of the codec, which will be heavily optimized using SIMD). And it provides binary-identical output compared to libvpx for all files in the vector testsuite. libvpx’ vp8/decoder/*.c plus vp8/common/*.c alone is over 10,000 lines of code (i.e. this excludes optimizations), with another > 1000 lines of code in vpx/, which is the public API to actually access the decoder.
Current work is ongoing to optimize the decoder to outperform libvpx on a variety of computer devices (think beyond your desktop, it will crunch anything; performance becomes much more relevant on phones and such devices). More on that later.
Things to notice so so far:
- Google’s VP8 specs are not always equally useful. They only describe the baseline profile (0). Other profiles (including those part of the vector testsuite, i.e. 1-3) use features not described in the specifications, such as chroma fullpixel motion vector (MV) rounding, a bilinear motion compensation (MC) filter (instead of a subpixel six-tap MC filter). Several parts of the spec are incomplete (“what if a MV points outside the frame?”) or confusing (the MV reading is oddly spread through 3 sections in a chapter, where the code in each section specifically calls code from the previous section, i.e. they really are one section), which means that in the end, it’s much quicker to just read libvpx source code rather than depend on the spec. Most importantly, the spec really is a straight copypaste of the decoder’s source code. As a specification, that’s not very useful or professional. We hope that over time, this will improve.
- Google’s libvpx is full of (hopefully) well-performing assembly code, quite some of which isn’t actually compiled or used (e.g. the PPC code), which makes some of us wonder what the purpose of its presence is.
- Now that VP8 is released, will Google release specifications for older (currently undocumented) media formats such as VP7?
(Posted at Sun, 27 Jun 2010 17:31:03 +0000 - Comments)

