This is what happens when you spend year in and year out thinking about the exact same topic… You start thinking about designing a new programming language!

Read the rest of this entry »

The final specs for Microsoft’s Xbox 360 have been public for some time now. Microsoft has even committed to a launch date of November 22 of this year. Predictably, the spec sheet raises more questions than it answers.

Read the rest of this entry »

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.

Pursuant to DVD Jon’s post about compiling and using the SMPTE reference VC-1/VC-9/WMV3/WMV9 decoder with VLC, I wrote an FFmpeg module to use the same reference code. Next, I will try to adapt it to xine. Though I hope we do not grow too collectively complacent with this decoder.

I tried decoding 3 different WMV3 videos from 3 unique sources. The reference decoder seemed to work fine on 2 videos but not on the third.

The third videos fails on all frame decodes, usually tripping errors about “FATAL ERROR: DecodeACRunLevel: AC coef array overrun”.

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 = 0×1000, ROQ_QUAD_JPEG = 0×1012, ROQ_QUAD_HANG = 0×1013, and ROQ_PACKET = 0×1030). 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.

I am pleased to announce that Kostya Shishkov has opened a new blog: Kostya’s Wild Codec World. Kostya is a talented codec hacker who has sorted out the details of the QPEG, TechSmith Screen Capture Codec (TSCC), IBM Ultimotion, Autodesk RLE (AASC), and Indeo 2, among other audio and video codecs, and has helped implement open source decoders for the FFmpeg project. His current target is Duck/On2′s old TrueMotion v2 codec. Soon we may finally be able to natively view the movies from the Final Fantasy VII PC game.

Head over to his blog and keep up with his progress.