Monthly Archives: October 2009

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.

A Lot Of New FATE Machines

Thanks to Thibaut VARĂˆNE for bringing an incredible number of new machines to the FATE table:

  • PowerPC / Mac OS X
  • ia64 / Linux
  • PA-RISC / Linux
  • Sparc / Linux
  • Sparc64 / Linux

As of this writing, the Sparc/64 machine is having trouble getting its first results uploaded to the FATE server. Those will hopefully start showing up soon.

Right now, none of the ia64 configurations compile successfully. This is indirectly how Thibaut learned of FATE (via this Roundup issue). No configuration is too marginal for us to track as long as someone has the resources to continuously run FATE cycles. If this is ever in doubt, just remember that Michael K. is testing FFmpeg on (Free)DOS via FATE.