The end-of-year summary

December 29th, 2008

Ok, let’s see what I’ve done this year:

  • simple IMA ADPCM encoder – Apple variant
  • worked a bit on different codecs – BMP, Fraps, Monkey’s Audio, TIFF, VC-1
  • got RV40 and RV30 finally working more or less as supposed (some garbage still occurs on some B-frames, but mostly both decoders produce watchable video)

So, what are the plans for the next year:

  • Find more time for FFmpeg development
  • Take part in GSoC (it gives a good reason to work on FFmpeg and also makes a good source of T-shirts)
  • Go abroad
  • And, of course, make FFmpeg closer to the world domination

For the last step I need:

  • Add more formats support to FFmpeg (WavPack lossy, Lucas Arts games formats, Bink, etc.)
  • Convince Mike finish his Xan4 decoder
  • Convince Robert finish his AMR-NB decoder (unless somebody beats him to it) and AAC-HE decoding support (those messages about SBR not supported are really nagging me)
  • Convince Kostya finish AAC encoder (hey, that’s me!)

So, let’s see what we get in the upcoming year.

The list of game codecs I want to have in FFmpeg

December 2nd, 2008

One of FFmpeg advantages is that it supports decoding of many fringe formats, especially game formats. My favourite is Sierra VMD but there are several other formats I’d like to be able to play:

  • LucasArts SMUSH (there was a patch for playing some variants, the rest could be made from ScummVM code)
  • Discworld II and III video format (if only ScummVM developers got the code for DW2 at least)
  • Indeo 4 and 5
  • Bink (if only certain person worked on REing it instead of formats used in EA games)

Code donations are welcomed 😉

Update: ScummVM has DW2 BMV decoder now.

RV40 is in

December 2nd, 2008

As you may know from other place, FFmpeg got RV40 decoder. There’s still some hope that FFmpeg will get RV30 decoder as well (it needs loop filter and squishing some bugs).

Some notes about performance:

  • PPC G4 1.42GHz — on par
  • Celeron 600MHz (inside ASUS Eee) — significantly slower (2 minutes of the same source decoded in 64 and 82 seconds by binary and native decoders respectively)

When I switch motion compensation functions from C implementations to optimised H.264 counterparts (they are slightly different so the picture quality gets worse) native decoder becomes faster than binary one by several percents on x86 and even faster on PPC. Conclusion: if you want fast decoding then submit SIMD versions of motion compensation functions.

RV: a small update

November 23rd, 2008

Hereby I declare that my RV40 decoder changed its status from “Well, it’s better than nothing” to “Good enough”. While there are still problems with chroma and jitter in B-frames due to wrong motion vectors prediction, luma decoding is bitexact on I- and P-frames.
I hope to weed them out and have decoding enabled in FFmpeg before next year. Maybe RV30 too.

For those who ask specs on RealVideo:

???????RealVideo

I hope the message is clear enough.

RV3/4 decoders present state: stalled again

November 4th, 2008

I’ve been very busy with the things outside FFmpeg yet I’ve managed to do something on RV3/4 decoders too:

  • Found and fixed an old bug with quantisation for DC coefficients.
  • Cleaned a bit RV4 loop filter.
  • Fixed chroma MC bug in RV3 decoder.
  • B-frames motion vectors are now closer to the reality in RV3.

What is missing:

  • RV3 loop filter
  • correct RV3 motion vectors calculation
  • RV4 motion compensation incompatibilities

The main problem is that I don’t quite understand why it’s working in the way it works and (in some parts) how it works. Hopefully it will be clearer next time I’ll look at it.

A RE Puzzle

September 21st, 2008

There is a codec, little is know about it.

Here are some of its features:

  • it codes frame as a three planes
  • it employs motion compensation
  • it employs old-school vector quantization — fill block, fill block with mask, …
  • each value in the stream is coded as the run of values plus actual value coded as several Huffman-coded nibbles (yes, each 4 bits are coded with own Huffman tree) plus sign bit if applicable
  • sometimes it performs DCT to restore block content

Try to guess what’s its name.

Hint: MultimediaWiki contains a description of the codec with the similar bitstream reading techniques, which is a relative of this codec.

And, no, since I’m engaged in AAC encoder, I won’t RE nor write decoder for it (at least in the near future).

A bit of audio news

August 31st, 2008

Looks like I soon will run out of titles, have to switch to something else then.

I’m still working on improving AAC encoder, for now I’m trying to fit trellis-based quantizer selection, then optimal quantizing will follow. In a process FFmpeg may get generic psychoacoustic model interface (there’s new IIR filters interface in SVN, with implementation for lowpass Butterworth filter only though).

In other news – there was a raise of interest to DCA decoder. Of course FFmpeg does not have one (wink wink), but there were some patches to correct tables used by it and improve speed (to nonexistent decoder, that is). Also there’s a person who hasn’t written a DCA encoder, he now reads development mailinglist and submits patches to out nonexistent decoder. Welcome!

Disclaimer. Sorry for political language, but I remember the troubles caused to Videolan because they had developed and hosted DTS decoder.

Also there’s a rise of interest to TrueSpeech, since it is used in some messenger (I’ve never thought it would be popular). I have to update information about it in MultimediaWiki a bit.

AAC: Life goes on

August 25th, 2008

Well, Summer of Code 2008 goes to end. I think I’ve completed my task – creating simple AAC encoder with psychoacoustics
(here are my application link and a rough task description). I’ve written AAC encoder with psychoacoustic model made after 3GPP TS26.403 and it seems to work fine (on multichannel sources too).

Now there’s a small catch – to be included into FFmpeg it should be optimal in the terms of coding. That means minding rate distortion, choosing optimal quantizers and codebooks, etc. Now it’s a bit harder task, so I think final encoder will be in SVN this autumn or later. Any pointers on information how to optimally encode some part of stream are welcome (for miscellaneous stuff like pulses, temporary noise shaping, etc.).

Stay tuned (and use Flac instead 😉 ).

A Round Date

August 14th, 2008

Today is the day when my first contribution to FFmpeg went to CVS.

You know that story – a curious programmer once decided to look how one of video codecs works, found out that was deflated MS RLE data expanded for bitdepths > 8bpp, wrote a decoder for it, adapted for ffmpeg, sent that decoder to one person and guess what that person did? Added necessary ties and committed it to FFmpeg CVS.

Well, since then I contribute to FFmpeg a bit of different stuff time from time. Plans for this year include AAC encoder, finishing RV3/4 decoder, pushing LucasArts SMUSH decoder to SVN, making Mike finish Xan4 decoder and some random stuff I’m not aware of now.

A bit more

August 8th, 2008

With low-pass filter my AAC encoder is more or less feature-complete. Of course there’s still more room for improvements but it’s pretty fine now. I’d like to submit it for review but it depends on some parts of AAC decoder and it’s still under review :-(. So I don’t have much to do until then.

So I switched to last GSoC task and hacked again at RV40 loop filter. Well, filter invoking pattern is almost there and I’ve fixed several bugs in actual filtering code. Bit it’s not there yet. Maybe in a month it will be so if AAC encoder won’t take all my time again.