Another codec in FFmpeg

March 22nd, 2006

Yesterday I’ve added implementation of Smacker demuxer and decoder, so you can enjoy you favourite pieces of video from various games.

I cannot credit the person who did the actual reverse engineering as he prefers to stay anonymous. Anyway, thank you very much!

The most interesting things in Smacker are Huffman trees. Smacker has trees by principle “every byte must have a tree”. Video operates with 16-bits values from Huffman trees, every of this trees stores values as two codes from Huffman trees. So you must construct two smaller Huffman trees before decoding large one. And packed audio data has also 1,2 or 4 Huffman trees depending if we have 8-bit or 16-bit data and stereo or not.

And now spotted inefficiencies in Smacker:

  • Smacker stores header information for 7 audio streams (!) yet I’ve never seen Smacker with two audio streams. Was that intended for internationalization?
  • Due to weird Huffman tree decoding procedure one bit is constantly wasted on stream. That means global Huffman trees for video lack 12 bits of waste (two support Huffman trees, one large Huffman tree, repeat four times) and audio chunks waste 1-4 bits depending on size. Not a big deal though.

And the final thought – the main difference between Smacker and M$ Video 1 is the packing scheme, block structure is almost identical. Anyone volunteering to write convertor from one format to another?

DosBox

March 4th, 2006

I think there is no need to introduce DosBox. And to make it even more usable DosBox developer niknamed Harekiet added screen output recording capability with his own codec ZMBV – Zip Motion Blocks Video.

This codec employs intraframes and motion compensation (and XOR’ing instead of substracting/adding difference). ZLib is used for packing. For more detailed description go
here
.

For now, 8-bit, 16-bit and 32-bit depths are supported by codec as for recording. And FFmpeg decoder is already available – I could not miss that codec and not port it.

JPEG-LS: decoder issues

January 18th, 2006

I’ve recently written a very baseline JPEG-LS decoder (grayscale lossless only) and had to deal with some issues, some of them listed in JPEG-LS standard (ISO 14495, ITU T.87), some are not:

  • Bitstream is escape-coded (after each byte 0xFF another zero-bit must be stuffed to avoid false JPEG markers detection). That requires special bitstream reader or another unescaped buffer.
  • There is no definite way to reverse error-mapping of run termination symbol. Even the reference code use another technique.
  • A lot of different modes (different bpps, pallettised images, two interleaving modes)

For now, lossless and near-lossless decoding is OK, plane and line interleaving are supported. With working decoder it will be simplier to write JPEG-LS encoder.

As I recently discovered, there is also ISO/IEC 14495-2 (or ITU T.870) standard – JPEG-LS extensions. For unknown reason ITU don’t send me another 3 free recs ID, yet I’ve managed to find some draft of this standard. Main changes: new mode – visual quantisation, new coding schemes – modified Golomb codes and arithmetic coding. I’m not sure if somebody support this anyway.

February: now grayscale/colour lossless/near-lossless JPEG-LS encoder and decoder are working (or simulate working well enough).

TrueSpeech – 97% complete

December 30th, 2005

Now my TrueSpeech decoder decodes compressed audio almost as well as original decoder. Why not 100% complete? It decodes audio slightly different from original decoder, so it may take some time in future to make my decoder identical.

I hope to see it in FFmpeg source tree soon.

A Brief Summary

December 30th, 2005

Here is a list of codecs I reverse engineered in some way.

Codecs RE’d by format analyzing

  • Apple QuickDraw
  • Autodesk RLE
  • Sierra On-line Audio
  • TechSmith capturing codec (aka Ensharpen)
  • Pinnacle/Miro XL

Most of those are RLE variants (actually 2 of 3 are MS RLE variants).

Sources->Description->New Code

  • LOCO codec
  • Duck TrueMotion 2
  • IBM Ultimotion
  • Winnov WNV1

The last one is re-created from tuner driver.

Binary RE’d

  • Creative ADPCM
  • Intel Indeo 2
  • Q-team QPEG
  • DSP Group TrueSpeech

TM2 and Final Fantasy

October 14th, 2005

There are a lot of variants of first two TrueMotion codecs. Final Fantasy (some number here) for PC uses TM2.

Differences from reference decoder: delta table size must be greater (64 instead of 32) and sometimes there is no data in stream, which means you should fill it with value from Huffman table).

Well, there is also TM2X awaiting.

VMWare Codec

October 13th, 2005

Recent VMWare virtual machines are able to capture their screen output and store it into AVI packed with their own codec. A quick study showed that this codec stores captured image in special type blocks, most of them are labeled WMVx (maybe VMW spelled backwards, but who knows 😉 ). Every block type has its own function to handle it. Blocks with labels WMVi or 0x00000005 can be found in almost every frame.

TrueSpeech – Some Information

October 12th, 2005

Here are main differences between TrueSpeech and G.723:
1) One bitrate (8 Kb/s) vs. two bitrates (6.3 and 5.3 Kb/s)
2) Lower complexity (TrueSpeech uses 8-point LPC, G.723 – 10-point LPC)

Frame structure is also differs, TrueSpeech packs everything into 32 byte frame where some values are spread between different doublewords (3d bit is in one dword, 2nd is in another one).

TrueSpeech – Old Audio Codec

October 4th, 2005

DSP Group TrueSpeech audio codec is rumored to be a relative to ITU G.723. That may be partly true: DSP Group took part in developing G.723, but if you study recommendation G.723, you’ll see that there are two methods used in this rec., and they differ.
Studies showed that TrueSpeech may be one of predecessors of G.723 – it is simplier, needs higher bitrate than G.723 and such. But I hope to use some ideas to reconstruct TrueSpeech decoder using methods from G.723.

TM2: Almost Complete

October 4th, 2005

My TrueMotion 2 decoder is almost complete. It just has some problems with chroma decoding in intraframes. I suspect this is because of some rounding errors and such. Original TM2 decoder used to store chroma in pairs – one 4 double word for 16-bit Cr and Cb and all calculations were done on those pairs.

For now, I’ll leave this decoder for some time and will post pieces of information about other codecs.