What I did during my summer

September 12th, 2007

It was very hot summer – both in terms of temperature and development process. I was writting decoder for the some codec (look at the category of this post if you don’t know what codec family was that, the fourth incarnation of it).

The main difficulty was
With the help of this tool written by Mike both he and I were able to capture some dynamic data during execution of the reference decoder and, basing on that information – to reconstruct execution flow, debug some variables and guess how some functions work. Still there were many functions that required assembly-human dictionary and took plenty of time.

What has surprised me during this work:

  • That is the first time I work with PIC code. Now I understand why some people believe it’s evil thing. Constantly calculating real addresses from offsets from GOT (global offset table) is no fun and switch(){} construction becomes extremely complicated. But now I know GOT address of that decoder by heart.
  • Passing parameters partly via stack and partly via registers (for example, source and stride are passed in register and destination as an argument) is also fun to watch
  • It’s quite unexciting when one function does virtually nothing except calling other function (with the same arguments).
  • There are several VLC reading techniques employed in reference decoder:
    1. Peeking if the next bits match some codeword in the table (i.e. iterate over table of codewords, look at the next k bits of bitstream and compare them with codeword)
    2. Using next 16 bits from the bitstream to find out code length (by finding prefix corresponding to the given length), then the difference between prefix and actual code (minus unused bits of course) is used to determine actual code value
    3. Using 256-element lookup table on the next 8 bits in bitstream to determine code length and value
  • And that’s not all – codeset for the first case may be stored in two ways – in pairs (code, length) and in one value using formula (1 << length) | code. And function using this has to determine most significant one position, remove it and then call show_bits().

I plan to give codec architecture review in my next post.

Samples, and lots of them

August 20th, 2007

Extremely big thanks to Mike, who sent me a dozen of DVDs with samples and they eventually got delivered (Roberto Togni also had sent me some disks with samples but they disappeared somewhere). It took about a week to deliver them to Ukraine. And a whole month to pass customs control.

But nevertheless it’s here and now I have enough samples to test my future and current decoders.

My thoughts on decompiling

July 18th, 2007

Here I want to present my thoughts on decompiler techniques I’d like to see. Maybe a lot of this is implemented somewhere but I haven’t seen working decompiler.

  • Possibility to load disassembly instead of disassembling by itself.
  • Good flow analyzer. REC, for example, produces a lot of silly gotos. Is it so hard to build directed graph for blocks, separate out conditional code and loops? IDA does so. And it’s pretty easy to recognize typical schemes like do{}while;
    if(){}else{} and detect break; in loop.
  • Watching ‘live’ registers. Each instruction may affect some registers and flags but some of them won’t be needed later (for example, sometimes substraction is used to modify some value and sometimes also result flags are checked too). And block of instructions may depend on some register values set before (if they are not modified before using). Boomerang had something like this but resulting code was too LISPy.
  • Reiterations – if decompiler finds out that function uses registers for passing parameters then code must be changed to reflect this.
  • Pattern recognition – it would be very nice if decompiler could recognize the same patterns over the code (in form: A = B+ constant; B = A | constant; ). And if it also could automatically label bitreading functions… But I fear that this is AI-complete problem.

Well, my rant ends here. Back to work.

Monkey Audio

June 10th, 2007

Thanks to Peter Lemenkov who pointed me to this Monkey’s Audio decoder implementation. It has four strong points: GPL, C, small and clean. Oh, it also takes less memory too.

The only drawback is that old APE files are not supported (but nothing can play them on PPC anyway without x86 emulator) so I’m eager see APE support in MPlayer, Xine, VLC (or maybe it’s there already?). Preferably via libavcodec 😉

Samples

April 29th, 2007

Looks like the best way to collect a lot of samples is to become a developer and maintain demuxer/decoder. You may receive a lot of samples that do not decode with it 😉

I’d like to thank three major contributors (from Dania, Netherlands and Japan) of VC-1 in HD-DVD/Blu-Ray samples. It is because of them VC-1 video playback is less buggy than it was before (I know it still is but at least it’s improving).

Why we should have another Monkey’s Audio decoder implementation

March 25th, 2007

Why should I bother about Monkey’s Audio? Because many pirates good people offer classical music in this format (FLAC is quite rare and I’ve seen WavPack only once).

What I consider wrong in Monkey’s Audio design:

  • No verson compatibility – each version alters decoding process
  • Huge blocks – some megabytes is huge indeed (WavPack – 64k, FLAC – even less), hence inaccurate seeking and big memory requirements
  • “Insane” profile – if it does not decode in realtime on my CPU that is unusable

What I consider wrong in MA implementation:

  1. There is only one implementation (with two known ports)
  2. It is not endian-safe (both generated WAV headers and < 3.92 decoding)
  3. OO in that case means “Object-Obfuscated” (i.e. too many files where you can’t easily find required code)
  4. Custom license

Maybe during GSoC somebody will write easily understandable portable decoder in Lavc that will allow playback of .APE in FFplay,MPlayer,VLC,Xine,etc. Otherwise I’ll have to do it myself.

VC-1: Some Bugs Squashed

March 25th, 2007

This and last weekend I fixed some bugs in my decoder so now watching HD-DVD/BluRay movies will be a bit more pleasant ;-). But for the whole watching and listening experience you should wait for E-AC3 decoder (maybe it will be implemented during Google Summer of Code).

As for me, my systems neither are fast enough to decode it in realtime (1.42Ghz PPC G4 and PII 266Mhz) nor can even display full picture (max. resolution is 1280×1024 but I’m fine with it). So you may conclude I’m not interested in watching HD and you will be right. But I care for decoder and will fix bugs in it as I do already.

VC-1: Complex Profile is supported a bit

February 28th, 2007

I’ve just added some support for WMV3 Complex Profile (aka old Advanced Profile).
I don’t know why most samples (users complaining about) I’ve met are anime. It’s a good chance they will work now.

And here is updated list of CP features explained:

  • RES_X8 – additional bit at the end of I-frame header pointing if this is normal I-frame or this is special coded frame (I’m sure that’s exactly WMV2/8 J-frame with different header)
  • RES_FASTTX – somehow interferes with P-frames but bitstream is not changed
  • RES_RTM – old P-frame format (header should be the same but some additions on macroblock level). This is also quite common in old WMV3 files. Not RE’d yet

VC-1: Blu-Ray is now supported too

February 10th, 2007

Now FFmpeg and MPlayer support VC-1 in MPEG2-TS streams which can be found on Blu-Ray discs.

Thanks to Martin for providing sample and Nico Sabbi for implementing handling of this in both FFmpeg and MPlayer.

HD-DVD decoding

February 7th, 2007

For those whom it may interest.
What are the things needed to play HD-DVD movies in open-source multimedia player?

  • Decrypted movie (use this tool)
  • Demuxer support
  • Video decoder
  • Audio decoder

EVO demuxer is really just slightly modified MPEG stream demuxer. FFmpeg and MPlayer fresh SVN versions support it (MPlayer was there first). I don’t know about other multimedia players but that’s quite easy to implement.

Video decoding: there are three possible choices – MPEG-2, H.264 and VC-1. First two should work fine, the last one should work but with some bugs (I will fix them eventually).

Audio decoding: is also tricky – standard AC3 audio will work, DTS is supported via libdca and E-AC3 is still to be figured out.

Conclusion – try current SVN of MPlayer and see if it works to you. And if you care about Blu-Ray support (and it does not work) – please provide a sample.