Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Musings of a File Format Hacker

May 17th, 2009 by Multimedia Mike

Some anonymous hacker recently made a name for himself (wait, can you make a name for yourself anonymously?) by ranting against the difficulty of working with certain Adobe file formats. It got me wondering if we could draw more attention to the FFmpeg program by littering the code with rants against the file formats we’re trying to re-implement. I’d like to think we’re above that, if only because the average FFmpeg hacker intuitively understands that no one ever meant for us to be able to re-implement these formats, at least not the proprietary formats.

Ironically, I think you’ll hear the most complaints from the crew where free, open formats are concerned.

You can look at a seemingly bizarre format and generally experience 1 of 2 reactions:

  1. What kind of moron thought of this format?! What were they thinking?!
  2. What did the creator of this format know that I don’t know? What were the original design goals and what problems were they trying to solve.

Over the years, I’ve trained myself to have reaction #2. I’m not saying I’m superior; on the contrary, the philosophy leads me down the wrong path sometimes when it turns out that the format’s originator honestly didn’t know what they were doing. In that case, I end up giving them too much credit.

Along these same lines, Joel Spolsky’s take is absolutely fascinating: He describes how the Microsoft Office formats evolved to their present complexity — not out of spite for third party programmers, but to meet the needs of the applications’ features.

Actually, an impromptu and unscientific audit of the FFmpeg code (grep’ing for certain keywords) does seem to indicate a high level of animosity towards Microsoft.

Suddenly, I feel revitalized regarding the MultimediaWiki and its charter. Someday, someone somewhere is going to want to know about that UMV format on Orpheo’s Curse.

Posted in Programming | 4 Comments »

Constantly Compiling Compilers

May 16th, 2009 by Multimedia Mike

At the outset of this FATE journey, I pondered how frequently I ought to update gcc from SVN and put new experimental gcc versions into service. At that point, I had some logistical difficulties in upgrading compilers due to my computer setup which made it a serious chore. But it’s much easier to do now– at least for x86_32 and x86_64, I know how to build one compiler that can build both binaries. Further, the C compiler only takes about 45 minutes to compile on my 2.13 GHz Core 2 Duo, leveraging both cores, and barring any other CPU activity.

So, if you know me, you should know that right about now I’m thinking… automated script! Here’s the pitch:

  • Write a new Python script that runs continuously which performs the following steps:
  • ‘svn update’ of my local copy of gcc-svn
  • If the SVN number is higher than the latest build, automatically build a new version and install it in its own directory
  • Wait 24 hours and repeat

This will run on my main FATE machine, so run the script at a low priority so it doesn’t take time away from the more important build/test operations.

So that seems straightforward enough, especially drawing on the experience I have with FATE already (this is basically a simpler version of the main FATE script). For bonus points, the script should also put the freshest compiler into service automatically so I don’t have to be bothered with the tedious, error-prone process. This will be a bit trickier, but it should be possible:

  • Contact the primary FATE MySQL database @ and update the relevant records in the configuration table.
  • Signal the FATE script to start using the new compiler versions. In the present arrangement, while I have 2 scripts in order to leverage 2 CPU cores, 1 of the scripts is in charge of the 2 gcc-svn configuration for x86_32 and x86_64. The compiler path is specified in a Python configuration file. I may have to modify FATE a little bit so that the script checks some independent file for the compiler location. Then, this new script can update that location.

There is also the matter of storing so many old gcc-svn compiler versions. I’ll likely clean that up manually at various intervals but its not terribly pressing; the main FATE build/test machine inherited a 400 GB hard drive when it went into service (which, you’ll be pleased to hear, is partially used in performing backup duty for the various domains).

Posted in FATE Server | 3 Comments »

TMV In FFmpeg

May 15th, 2009 by Multimedia Mike

I’m pretty sure that Trixter is equally honored and disturbed that Daniel Verkamp has contributed a TMV playback system to FFmpeg.

Neo from "The Matrix", transcoded into TMV format
VLC playing the8trix.tmv transcoded by FFmpeg to PNG-in-AVI

To review, TMV started out as a joke, or perhaps a dare. It was a challenge to try to play 30fps full motion video on an original PC. “Original PC” is defined as 4.77 MHz 8088 CPU, CGA graphics, and original 8-bit Sound Blaster.

For further creepiness, Trixter, here is a new FATE test which will guarantee that FFmpeg reliably decodes TMV files on dozens of different CPU/OS/compiler configurations.

Speaking of FATE, I have neglected to mention that MichaelK has kindly contributed continuous testing resources for NetBSD and OpenSolaris, both on x86_32. Further, Måns continues to work his little ARM-based Beagle Board to the bone and has added more compiler configurations.

Here are some more new FATE tests (thanks to Vitor for adding specific tests to the FATE Test Coverage page):

One more thing– can anyone make FFplay compile under Mac OS X? I thought I succeeded once but now I can’t seem to do it. I would like to take screenshots as seen above using FFplay. But I can’t get the program to work correctly anywhere. Maybe it needs to be formally deprecated… or I need to think of a way to continuously test it via FATE.

Posted in FATE Server | 7 Comments »

Orpheo’s UMV Format

May 5th, 2009 by Multimedia Mike

I was contacted by someone who is performing an in-depth investigation of the data files for the game Are You Afraid of the Dark? The Tale of Orpheo’s Curse. During the course of said investigation, he happened across my old Multimedia Exploration Journal entry where I briefly inspected a CD-ROM copy that I had procured.

Cover art for Are You Afraid of the Dark? The Tale of Orpheo's Curse

Oddly, my notes concluded that there was nothing interesting on the disc and that the contents would fit on a standard 5.25″ floppy disc. This might be a case where the game was unremarkable, multimedia-wise, for for its original floppy-based release but was upgraded for a subsequent CD-ROM release.

He was able to work out the identities of many of the data files. These include AIFF, MID, and even tracker module formats like 669 (no, Colin, I don’t have that loader finished; to the rest of you… nevermind). He also found what we suspect is a FMV format called UMV and provided 3 samples. I looked at it briefly but nothing jumped out at me, save perhaps for some signed 8-bit PCM audio chunks. This would be unusual since most 8-bit PCM of the time was unsigned.

I know you want to tinker with the samples, so here is the requisite MultimediaWiki page, along with the 3 UMV samples.

No multimedia format is too obscure. That reminds me– I have a multimedia-looking file hanging around on one of my filesystems called CREDITS.NXL. Does that sound familiar? Did anyone reading this send that to me? What game is it from? I suspect I received it from a kind, curious contributor but was too lazy at the time to post details on the wiki.

Posted in Game Hacking | 7 Comments »

« Previous Entries Next Entries »