Kostya's Boring Codec World

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.

Yesterday I’ve rewritten decoder using FFmpeg’s functions from h263 decoding. Now the code is simplier and decodes more I-frames correctly but the problem with AC prediction remains.
Here is the output of new decoder, the same scene:

Yesterday I’ve managed to beat more or less sane I-frame decoder.
It is not very good now but at least it works and produce something that could be recognized without lots of imagination:

Yesterday I’ve managed to hack FFmpeg bits of VC-1 decoder to actually parse and decode simple profile I-frames. Bits consumed are fine. But there is no sane picture yet. DC prediction is not good and AC coefficients also needs some operations, but at least they are decoded correctly.

OK, 8×8 transform is slightly optimized too.

This version gives 7x gain on PII and 15x on G4.

Here is vc1itrans.c file from VC-1 reference decoder with replaced transform.

See here
how to use VC-1 reference decoder in FFmpeg
and just replace one file in libvc1 with my version before compiling.

I was honoured to implement VC-1 decoder in course of Google Summer of Code.

I had almost no time to do anything this week but at least here is straightforward optimization of 4×4 transform.
Speed gain varies from 4 times (PII-266) to 7 times (PPC G4-1.42 GHz). My name is not Niedermayer and I’m not sure how to further optimize it / rewrite with MMX/AltiVec but it’s a good start. 8×8 transform will follow soon (I hope).

The test code is given below.
Read the rest of this entry »