Kostya's Boring Codec World

For those who interested, here is a very experimental patch to enable decoding of WVC1 codec in FFmpeg. I’m currently searching and downloading sample files but it is already tested a bit.

Instructions:

1. Get FFmpeg sources (r614x should work)
2. Download and apply patch (cd ffmpeg; patch -p0 < vc1-advanced.patch)
3. Run configure and make

As always, non-working samples are welcome.

If you look in VC-1 standard specification it’s hard to find header specification for Simple/Main Profile (at least I was unable to do so in comittee draft available – only some hints in bitstream container format). Was that intensional or not?

FFmpeg old and not working vc9.c contained header parsing code and reference decoder does this too. This header contains a lot of ‘reserved’ flags which hidden meaning become clearer if you meet with them:

• RES_RTM_FLAG – should be set to ‘1’ but all old WMV3 files have it set to zero. For now you can call it ‘P-frames will be decoded correctly’ flag as old WMV3 has I-frames decoding identical to standard
• PROFILE=2. This is not allowed profile but in vc9.c it was called “Complex Profile” and really is Advanced Profile for old WMV3. I don’t know why but one sample was decoded when I changed profile value to “Main”, other Complex Profile samples produced garbage (but they also had RES_X8 and RES_FASTTX flags set).

There is also new M$ codec – WVC1 which is not decoded by reference decoder.

So here is a small list of huge tasks:

1. Find out how to decode P-frames when RES_RTM_FLAG=0 thus enabling decoding of many old WMV3 videos
2. Find out how to parse WVC1 movies
3. Support Complex Profile (not really important)

Some notes on forward transform.

For 4×4 transform matrix is:

17 17 17 17
22 10 -10 -22
17 - 17 - 17 17
10 -22 22 -10

And suggested norm is (8/289 ; 8/292; 8/289; 8/292)
The forward transform for (A B C D ) will be:

A1 = (17 * A + 17 * B + 17 * C + 17 * D) * 8 / 289;
B1 = (22* A + 10 * B - 10 * C - 22 * D) * 8 / 292;
C1 = (17 * A - 17 * B - 17 * C + 17 * D) * 8 / 289;
D1 = (10 * A - 22 * B + 22 * C - 10 * D) * 8 / 292;

Of course, don’t forget to round result.
I tested it on Octave and it proved to be correct.

Optimization is also straightforward: compute (A+D) , (B+C), (B-C) and use their sums/differencies.

Yesterday I finished B-frames parsing support and to my surprise all of B-frames in test streams were decoded correctly even without motion compensation. I don’t know why all of them are composed from intra-blocks only. And they are not MS-invented BI-frames either.
While I understand that’s legal I still cannot understand why it was done so.

I’ve written a small and quick demuxer for VC-1 Simple/Main profile test bitstreams (source available Here).

Most of the samples are recordings of Football training. You can see “Windows Media” logotypes on some players’ uniform.

And rarely clips with some singer occur.

Anybody can guess why?

Yesterday I tried to decode WMV3 Advanced Profile (fourcc: WVC1) and it failed. After I changed decoder to skip 5 bytes (one unknown, and 00 00 00 01 0F indicating that sequence hader is started) it began to decode frames. And failed. The only correctly decoded frames are skipped frames.

So no Advanced Profile reference decoder for now.

I won’t be able to work at VC-1 full day for a week, but it does not mean I won’t code at all. Meanwhile I plan to write demuxer for test bitstreams. Annex L in standard specifies format for all profiles but advanced profile bitstreams use their own format: 0x00 0x00 0x01 where opcode may signal frame start, field start, slice start, etc. This one likely to be done with libavcodec *Parser mechanism.

And here is what I’ve done to present time.

Present decoder status:

• Simple and main profile supported

What is not implemented:

• B/BI-frames (samples needed)
• Reduced range support (the same)
• Loop filtering for P-frames (I don’t think it’s needed now)

Known bugs:

• Chroma in P-frames is wrong
• Sometimes motion creates double borders on objects

Yesterday I’ve finished P-frames support in VC-1 decoder. That does not mean it now decodes all files of course. But at least simple/main profile without B-frames and advanced features should be decoded more or less correctly (excluding chroma).

So, it’s time to do the bug squashing:

• Correct chroma mode
• Implement MV intensity compensation (now it mostly produces errors)
• Implement coefficient scaling
• Make all P-frames parse and decode correctly

Looks like VC-1 movies with B-frames are rare so another task is to find samples.