Pending work for FFmpeg

Here are some pictures decoded with game decoders I’ve more or less finished in my free time:

While logotype in the middle should be recognisable to almost everybody (it’s from video file embedded in another player/converter for that format), others are not so famous.
Yes, colour planes are swapped but that’s not critical.

Left picture is taken from Wing Commander IV trailer packed with Xan codec. It has a very long history — it was 90% complete even before I joined FFmpeg project. The only caveat was that it outputs YUV format while Mike thought it was 16-bit RGB. Also nobody was interested in completing it (including Mike and me). Well, it’s almost there.

Right picture is from Descent III intro encoded with Interplay Video 16-bit version. I’ve looked at it once, almost got it right. Main thing I missed is that is stores motion vector data at certain offset, not along with other data as it did in 8-bit version. Now it plays fine though.

Another funny thing I remember is that there were complaints on detection of 16-bit variant. And what do you know? That information was available for ages at container description page. Sometimes it’s useful also to read Multimedia Wiki, not only write to it.


What next? I don’t know, there so many things to do — finish Flash Video 2 decoder, integrate Auravision 1/2 decoder before it rots, have another stab at some formats like Apple Intermediate codec or some codecs from Windows Media family.

At least I know that FFmpeg may be a bit closer to its one of unofficial ultimate goals — converting everything.

5 Responses to “Pending work for FFmpeg”

  1. Great work on the Xxan codec. I do hope we can get closure on that one soon. I started trying to reverse engineer that … I think back in 2002. It seemed pretty simple to decode but then there was the rendering phase. That’s probably where I got hung up on the RGB16 output.

    What happened was that the person who wrote the Wing Commander Movie Player ( http://hcl.wcrevival.de/movie_player.html ) reverse engineered just enough about the DLL to shove binary data through it. After the stream is decompressed, it can be rendered in a number of formats. The original author RE’d the path that involved interlaced (actually, every other line is black) RGB16 output. The craziest part is that he also ripped a gigantic lookup table and hardcoded that into his playback code (128 Kbytes of data, compiled, IIRC; but nearly a megabyte in C header format). I figured successfully RE’ing the codec would mean RE’ing the method for generating that LUT.

    Don’t worry about me, though– I’m still working on thoroughly useful multimedia stuff when I get a chance: in particular, I’m optimizing the VP3/Theora decoder, the most worthless codec out there. 🙂

  2. Vitor says:

    What remains for Bink decoder to be bit-identical? This has been one of the last popular unsupported formats 😀

  3. Kostya says:

    Vitor, I don’t know – we need samples to test. Luckily, Bink is used in more than one game.

  4. If I can get this idea off the ground, I should be able to automatically summon and test an enormous corpus of sample BIK media: http://multimedia.cx/eggs/archivists-burden/

  5. […] First off, FFmpeg’s Interplay MVE decoder finally supports 16-bit video mode in addition to the original palette mode. I would post a pretty picture showcasing this (as I often do for new game-related formats) but Kostya has already done the honors. […]