I find it useful to reaffirm my core goal in this whole multimedia hacking adventure. I started out with this goal back in 2000 and it has not changed:

I want one multimedia player that:

• can play any multimedia format I throw at it
• is simple to install and use (simple and consistent graphical user interface)
• runs under Linux
• is free
• is open source

Whenever I evaluate the state of multimedia support on Linux, I use the metric described above. Is it a difficult goal? Certainly. Is it possible? Absolutely. There are problems, but none could be described as insurmountable.

This morning’s project was to make the SMPTE VC-1 reference decoder work with my home project, the xine media player. This is mostly an academic exercise for me personally and I do not see much point in releasing the source code. The only people for whom it would prove even marginally useful would be xine users like me who run on non-x86 platforms (AMD64 for me). And even then you need to have an rather fast CPU since the reference decoder is not designed with speed in mind. E.g., there is probably a better way to compute those inverse transforms rather than performing 2*m*n multiply/add operations for each m x n block.

Update: I just realized that the inverse transform is not the most comical of the inefficiencies. Examination of the variable length code (VLC) functions reveals that the reference decoder uses an O(n) VLC decoding algorithm, where n = the total VLCs in a table. I have never seen this before. I have never really thought to evaluate running efficiency of VLC algorithms until now. Naive tree-based VLC decoders are roughly O(log n) while table-based VLC decoders strive to be O(1), or constant time.

Not that the O(n) VLC decoder is bad considering the application. To the contrary, the code is very simple to understand. I just thought that some of the trade-offs made to accommodate readability vs. efficiency are humorous.

x86 xine users would be better served by continuing to use the Win32 binary codecs until we (likely the FFmpeg people) complete a viable open source decoder. If you are a non-x86 xine user, email me if you want WMV9 support now.

Little by little, proprietary multimedia codecs become open source, one way or another. Sometimes, the originating companies release the code. Eric Lasota tipped me off that id recently saw fit to release the source code for Quake III under the GNU GPL, just as they have previously done for their Doom 1 & 2 and Quake 1 & 2 engines. You can download the source code file (quake3-1.32b-source.zip) from this FTP directory. What makes this development particularly pertinent to multimedia hacking is that the file quake3-1.32b/code/client/cl_cin.c contains the formal decode engine for the RoQ file format, which is the FMV format used in Quake III and games derived from the Q3 engine (such as Jedi Knight II, Return To Castle Wolfenstein, and American McGee’s Alice).

So anything that may have been confusing should be clear upon looking at the official source code. Dr. Tim Ferguson originally reverse engineered the format. From the official source it appears that there were some other features perhaps planned and not implemented, or omitted from the final version. These features apparently include a JPEG encoding mode. In fact, there are 4 extra chunk types that go largely unused (ROQ_QUAD = 0x1000, ROQ_QUAD_JPEG = 0x1012, ROQ_QUAD_HANG = 0x1013, and ROQ_PACKET = 0x1030). The context in which the JPEG mode is defined implies that a frame could be encoded using a JPEG or JPEG-like method. I am not entirely sure what HANG means but it could indicate that the current frame is unchanged from the previous frame.

Eric also points out that the code does, in fact, immediately decode the codebooks from YUV -> RGB16 and everything is processed in that colorspace. I have long suspected that this is a holdover from The 11th Hour which is where the RoQ format got its start. The FMV needed to be played back on 1995-vintage PCs which were not very capable of playing YUV data directly, and converting full frames of YUV data -> RGB would not have been plausible.