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.