Archive for December, 2008

The end-of-year summary

Monday, 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

Tuesday, 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

Tuesday, 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.