Thanks to Måns for modifying the FATE script in a way that supports automatically cross compiling FFmpeg for a different target CPU on a faster host machine, transferring the binary to a machine specimen that runs the target CPU in question, and remotely asking the target CPU to run the battery of FATE test specs. The upshot of all of this is that FATE is effectively running on an ARM-equipped Beagle Board and contributing results back that anyone can view via the main FATE page.
I hope to get his changes rolled into the main script soon. It’s great work, and I’m hard-pressed to name another continuous integration system that can operate on such diverse platforms, environments, and circumstances.
I dusted off my old Sega Dreamcast this evening — the one I used to do homebrew programming on — and enjoyed some games. As I was playing, I realized that the next evolution of FATE would be to get it to continuously run automatic cross-compile and test cycles on the Dreamcast’s SH-4 via a custom serial protocol, similar to what John Koleszar described in this comment.
But I have a few more FFmpeg code paths to cover before I can even think about that.
I have been considering the idea of adding gcc cross compilers to FATE. At first, I just want to try compiling some binaries to make sure the builds stay working; testing may come later via qemu or physical hardware.
There was once a time when I was reasonably competent at setting up cross compiling toolchains, when I was developing software for the Sega Dreamcast on a hobby basis (SH-4 and ARM toolchains). But I seem to have lost the skill somewhere along the line. Fundamentally, it involves configuring GNU binutils with an alternate –target than the default, native platform. The trouble is that it’s difficult to figure out exactly what the target is named. I recently tried to set up a toolchain for MIPS, just in case I should come into possession of a laptop with such a CPU. I couldn’t figure out if I needed a mips-elf target, or a mips32-elf target, or perhaps a mips32-linux-elf target. Nothing I tried worked.
Maybe I just don’t have the right targets. What would be some good, useful, cross-compiled targets to be building continuously with FATE? I suspect that, at a minimum, all of the targets for which FFmpeg has SIMD optimizations: Alpha, ARM, Blackfin, PS2-MIPS, SH-4, and Sparc.
Engineering is about trade-offs and compromises. One of the most fundamental trade-offs to be made when designing a storage format is whether multi-byte numbers will be encoded as little or big endian numbers. But have you ever studied the data structures involved in ISO-9660, the standard filesystem format for optical discs? It seems that the committee tasked with developing this standard were unwilling to make this one tough decision and specified all multi-byte numbers as omni-endian. I just made that term up. Maybe it could be called bi-endian or multi-endian. The raw detail is that multi-byte numbers are stored in little endian format and then in big endian. For example, 0x11223344 is stored using 8 bytes: 0x44 0x33 0x22 0x11 0x11 0x22 0x33 0x44.
Do any other filesystems take this compromise? I am not that versed. I have studied the odd game-related optical filesystem; I had to write a manual ext2 searching tool for a sysadmin class; I also had to try to recover a virus-corrupted FAT16 filesystem (to no avail; that virus cleanly chewed up some of the most important sectors).
Anyway, if I were to go ahead and try for a new FUSE driver for ISO-9660 (or modify an existing driver), I would want to go after the main format. Plus, I would want to natively interpret that CISO format on the fly. Further, I would use this as a platform to understand what is so special about the apparent ISO-9660 data ripped from a Sega Dreamcast GD-ROM.
Are there any other ISO bastardizations to target for such a tool?
FFmpeg now includes support for the Sofdec middleware format thanks to Aurel Jacobs and Mans Rullgard, as well as everyone who has made FFmpeg’s MPEG video decoding what it is today. Sonic the Hedgehog salutes you:
Sonic Adventure 2: Battle
Sofdec is a multimedia middleware format that was used heavily on the Sega Dreamcast. Indeed, if you booted a DC game, there might have been a 50/50 chance that you would see Sofdec’s technology insignias among the many obligatory corporate logos. Sofdec still survives to this day and is seen on various GameCube games (often developed by Sega’s subsidiary houses). It probably runs on all the other consoles as well. In fact, I see that MobyGames maintains a game group for CRI-using games.
The thing about Sofdec files is that they are fundamentally MPEG files with MPEG-1 video. The only thing special about them is that they are packaged with a custom ADPCM format called CRI ADX. I checked out the new FFmpeg support with files from a variety of games. One of the biggest problems is blocky output. On files from certain games (for example, F-Zero GX, Resident Evil 4, and Starfox Assault), it almost appears that only DC data is being decoded. FFmpeg does not report any decoding problems. The result is something like this:
I am pretty sure that the above is supposed to be the official GameCube logo, which looks like this:
There are also a few videos from Resident Evil: Code Veronica X on the GameCube that display as a square 320×320 frame, which is not correct:
I wonder if aspect ratio information is stored inside this file format, or if perhaps the data is in some other place in the game’s data. Not all of the videos in the game are like this, though.
Many new samples are available in the usual place.