Kostya's Boring Codec World

I’ve finally finished Moving Blocks HQ and REing Super Moving Blocks. The main changes from vanilla Moving Blocks is a larger MV table (vectors can now target as far as 8 pixels instead of previous 4 and the fact that now raw luma samples use delta coding and static Huffman codebook. The only difference between two newer variations is that Super Moving Blocks uses 6-bit luma samples (and larger codebook for handling twice as many possible delta values).

With this part done, all is left is adding support for various Escape codecs as well as raw audio and video formats. And ACEFilm of course, but that’s a separate format.

As people remember, Eidos started as a company offering video editing software for Acorn RISC machines (do not confuse with Acorn RISC Machines company), but later it merged with a game publisher (more than once) and now it’s a Japanese game company. Yet the codecs they developed survived for some time in the games.

Since I was looking at ARMovie and found decompressors for Escape 100 and 102 codecs (essentially the earliest in the series) I looked at those as well and here’s a brief overview.

Both codecs are almost identical in design (only the luma code seems to differ), they operate on 160×128 frames in 5-bit YUV420 format, operating on 2×2 blocks. Chroma values are picked from the table of 256 combined U/V values. The codecs code data as a variable-length code for the number of blocks to skip (the same code seems to have survived until Escape 124) and the following block update mode (luma and/or chroma). As I said before, chroma values are taken from the table or left intact from the previous frame; luma values are coded two 5-bit values and 3-bit mask telling which value to use for the block elements (first element in the block is always the first value of course).

And that’s it. No other modes, the only frame header is 32-bit word with codec ID (later revisions decided to add frame size and even flags that affect decoding process). Nevertheless it’s rather interesting to encounter codecs that use simple two-colour vector quantisation (and fixed codebook for chroma pairs) without any additional image transformation tricks (e.g. motion compensation beside skipping, or even allowing raw blocks).

Implementing decoders in NihAV goes slowly since ARMovie essentially stores track data all clumped together and requires a packetiser to split it into video frames. Of course it can always get worse: Actimagine VX stored audio data right after video frame data without storing video part size so you can decode audio only after you’ve decoded video part of the frame. Anyway, I’ve managed to hack a demuxer and even a working Moving Lines decoder. Before tidying it all up and implementing other decoders, I want to give an overview of other Acorn video codecs.

Surprisingly enough, Moving Blocks has some documentation (from the authoritative source nonetheless!). Of course it contains some minor mistakes, mostly some values in motion vectors table (some values have their minus sign forgotten and the order or some values for spacial copy vectors is wrong).

For those who’re simultaneously too lazy to read the description and curious enough to know how the codec functions, it’s simple: frames are split into 4×4 blocks, each block has a variable-length code for its coding mode—raw data (subsampled YUV apparently), motion compensated block (with a variable-length motion vector pointing to a previous frame or an already decoded part of the current frame) or split into 2×2 blocks with either raw or motion-compensated mode.

But that’s not all, the codec got development as Moving Blocks HQ. I have not fully analysed it yet but the main changes that now motion vector table is four times larger and includes extended range motion vectors, there’s no longer raw mode for 4×4 blocks (it got replaced with a dedicated skip mode) and raw 2×2 blocks use static Huffman coding (or at least it looks like that; also maybe it uses delta coding but I’m really unsure about that).

And of course they did not stop on that and created Super Moving Blocks. From what I can see it has a larger Huffman codebook plus slightly different modes (like skip modes for 2×2 blocks). I was unable to locate samples for it so it’s a theoretical exercise.

Apparently there was also yet another attempt called Moving Blocks Beta but since I could not find a decoder for it, we can only speculate what changes it had.

At least there will be something to document on The Wiki when I’m done with all this.

Update: now as I have a working decoder, I can say that I was wrong about some things in Moving Blocks. The specification is correct except for some motion values. As for the later revisions of the codec, I’ll postpone them as REing them will involve manual decompilation. Luckily for me there are more codecs to look at.

While I’m trying to write a decent demuxer for the format, here’s the description of the first codec for it (I’ll postpone the rest until I implement a demuxer and a decoder for this one).

So, Moving Lines (aka codec 1) works on the usual 15-bit pixels and packs data into 16-bit words (sadly Ghidra fails to realise that LDR loads 16-bit data on ARMv4 but I’ll manage). Bits are read LSB first.

Here are patterns for the opcodes: first (low) bit signals a special code and when unset the rest of the word is a raw pixel. For special codes it’s easier to look at the top bits first though.

• 0x0001..0x8FFF—copy the amount of pixels stored in the next 6 bits using displacement table (from -8,-8 to 8,8 excluding 0,0) with table index stored in the following 9 bits;
• 0x9001..0xE5FF—copy data from the already decoded part of current frame, next 6 bits are amount of pixels to copy, the following 8 bits code the displacement (from -9,-9 to 9,0);
• 0xE601—end of frame marker
• 0xE603..0xEFFF—run series, 10 bits code run length minus one and the next codeword is pixel value;
• 0xF001..0xF7FF—skip series, 10 bits code skip length minus one;
• 0xF801..0xFFFF—raw data values, 10 bits code code number of values, the following codewords contain packed 15-bit values. In the end bitstream is aligned to 16-bit boundary.

Since video data is usually clumped together in large chunks you need to keep decoding it until you encounter end-of frame marker (and then data for the following frame starts).

That’s all for now, hopefully more will come soon.