Author Archives: Multimedia Mike

State of the Art Compiler Optimization

Felix von Leitner delivered a talk at the 2009 Linux Kongress about the state of the art in compiler optimization (link to PDF slides). Presentation slides by themselves are not a good way to understand a talk and it would be better to learn if video for the actual talk is posted somewhere. Compiler optimization (or lack thereof) is fairly important to FFmpeg developers.

The talk analyzes how LLVM, icc, MSVC, Sun C, and gcc generate fast code in this day and age. One basic theme I gathered is that coders should forgo clever C optimizations as they tend to be counterproductive. I wish I could believe that, but there was that recent episode where I optimized FFmpeg’s Theora decoder by removing structure dereferences. I’m sure that other performance-minded multimedia hackers will have other nits to pick with the broad generalizations in the presentation. I call your attention to the fighting words (which I have taken out of context since it’s such a fun quote) on slide 41: “Note: gcc is smarter than the video codec programmer on all platforms.” Further, slides 53-55 specifically call out madplay for inline ASM that allegedly didn’t improve efficiency vs. what the compiler could achieve with the raw C code.

On the whole, the findings are probably quite accurate for the kind of C code that most people need to write (e.g., “No need to write a >> 2 when you mean a/4!”).

Speaking of compilers, FATE now covers Intel’s 11.1 series C compiler for both 32- and 64-bit icc. I have also updated the stale snapshots of the gcc-svn for my machines (I still need to write a tool to do that for me automatically and continuously).

Roketz VQM

I’ve been on a gaming kick lately. I found a game in my collection called Roketz; the full DOS game can be downloaded from the publisher. The game has 2 files bearing the extension VQM that appear to be FMV files. Wiki and samples.

Roketz comes from a company called Bluemoon. According to their website, they’re also responsible for building the technological foundations for 2 well-known pieces of software: Kazaa and Skype. I’ve never used either, personally, but I understand that Skype uses a custom vocoder called SILK. Maybe Roketz and VQM is where the team got their start in codec technology?

iPhone Developments

Wikipedia’s knowledge of compilers credits the first compiler to Grace Hopper in 1952 (for a language called A-0). I suspect that if blogs existed in 1952, we would have been treated to rants such as:

I, personally, have a problem with a developer who feels entitled to be able to develop for a computer without investing the time to learn the machine opcodes or punch card formats that the machine was built around.

This is one of the arguments I have been hearing this past week after my employer announced an upcoming method for exporting Flash/AS3 projects as iPhone apps. It strikes me as an age-old argument between low vs. high level languages, that’s all. I chortle when recalling how certain people urged me to construct the FATE system in POSIX-complaint, ANSI C for maximum portability and speed instead of using a language like Python. Nowadays, that Python code is testing FFmpeg on a dozen different CPUs running 10 different operating systems. It makes me shudder to think of how much work it would have been to write the FATE script in straight C and how little benefit doing so would have brought.

In other groundbreaking iPhone news, Mans recently announced that FFmpeg can be built for the iPhone out of the SVN tree with only a minor modification to Apple’s iPhone toolchain (call the SDK police!). This is a feat that has thus far proved challenging, as Mans outlined here. I understand it will be a little difficult to continuously test FFmpeg on either a real iPhone or an emulator. However, I’m planning a revision to FATE’s architecture so that certain configurations can be marked “build-only” and forgo the test phase. This will also be useful for Hitachi SH-4 and perhaps other architectures that FFmpeg supports but for which we don’t have access to hardware for the sake of continuous testing.

Whenever the notion of compiling and running FFmpeg on the iPhone crops up, it prompts me to wonder why. Why do people care about this? Are they transcoding media on the iPhone? Are they republishing old games and using FFmpeg’s numerous game-oriented decoders for direct playback instead of doing the sensible thing and transcoding the original media to MP4/CAF/H.264/AAC for native playback through the platform’s frameworks and hardware acceleration? Is it just a point of academic curiosity thanks to the fact that FFmpeg is quickly becoming a standardized metric of compiler quality? Why?

13 Architectures

An impromptu query from the FATE database:

mysql> SELECT DISTINCT(architecture) 
  FROM web_config_cache 
  WHERE revision IS NOT NULL 
  ORDER BY architecture;

This yields 13 architectures currently being continuously tested in FATE:

+--------------+
| architecture |
+--------------+
| Alpha        | 
| ARMv5TE      | 
| ARMv7        | 
| AVR32        | 
| ia64         | 
| MIPS         | 
| PA-RISC      | 
| PowerPC      | 
| PowerPC 64   | 
| Sparc        | 
| Sparc64      | 
| x86_32       | 
| x86_64       | 
+--------------+

I suppose it’s questionable to treat ARMv5TE and ARMv7 as truly separate architectures. Still, it’s not a bad list of CPU coverage. It makes me wonder how it stacks up to the Linux kernel in terms of CPU support. According to Wikipedia, Linux still has the advantage.

One day I’ll figure out a way to continuously test FFmpeg on a Hitachi SH-4 using my old Sega Dreamcast. That’ll bring us closer.