Lagarith

• FourCC: LAGS
• Website: http://lags.leetcode.net/codec.html
• Samples: http://samples.mplayerhq.hu/V-codecs/lagarith/

Lagarith is a lossless video codec intended for video editing and archiving. It is also suitable for video capture on high-end systems. It is capable of handling RGB24, RGB32, RGBA, YUY2, and YV12 input video. To facilitate editing, Lagarith only supports keyframes, and optional null frames. Other features that make it suitable for video editing include a simple configuration interface, a good compression to speed ratio, full backwards compatibility with earlier versions of the codec, and a reduced resolution mode that is useful for 'bait-and-switch' editing.

Features

Compression

If the image is RGB(A), the red and blue channels are converted to their difference from the green channel (YUY2 and YV12 cannot be similarly converted). The image then has median prediction applied to it to make it more compressible (similar to Huffyuv's median prediction). Next, each channel is compressed independently. The channels will have a modified run-length coding scheme applied to runs of 0 if it reduces the length of the byte sequence. Runs may be triggered by 1, 2 or 3 sequential 0 values depending on which (if any) reduces the length the most. Run-length coding typically improves both compression and speed. If the modified run-length coding does not reduce the sequence length, the sequence is passed through unchanged. Next, the frequency for the different values in the byte sequence is tabulated and stored using Fibonacci coding. Finally, the byte sequence is compressed using a range coder and the frequency table.

Additionally, in special cases where a frame is a solid color, the frame may be stored as just one uncompressed pixel.

Multithreading

The codec allows the user to specify if multiple threads should be used; this can be used on dual-core systems to significantly improve speed. The threading takes advantage of the fact that the channels are compressed independently & uses a separate thread for each channel. The output data is the same regardless of whether or not multithreading is enabled.

64-Bit Support

A beta version of the codec is available for Windows 64. All features except reduced resolution mode are supported by the 64-bit version, and the 64-bit version is significantly faster than the 32-bit version on a 64-bit AMD processor. The output data is identical for the 32- and 64-bit versions.

Data Format

Lagarith data is typically transported in AVI files. If the frame is 0 bytes long then the frame is a NULL frame. Presumably, the frame is unchanged from the previous frame.

Byte 0 is the 'frame type' of an encoded chunk, and indicates the type of coding used to decode the remainder of the chunk. The supported types are:

• 1: Uncompressed
• 2: Unaligned RGB24
• 3: Arithmetic coded YUY2
• 4: Arithmetic coded RGB24
• 5: Solid greyscale color frame
• 6: Solid non-greyscale color frame
• 7: Obsolete arithmetic coded RGB keyframe (Maintained for backwards compatibility)
• 8: Arithmetic coded RGBA
• 9: Solid RGBA color frame
• 10: Arithmetic coded YV12
• 11: Reduced resolution frame

Any other value is considered to be an error.

Arithmetic Coded Frames

This is the general layout for frame types 2, 3, 4, 7, 8, 10, and 11. Following the type byte, the next 8-12 bytes in the chunk represent 2 or 3 32bit integers that tell the offset to compresed channel data. The first compressed color channel data begins immediately after the offset data. For YUV and RGB formats, there are 2 offset values (2 integers, 8 bytes), with the offsets pointing to G/U and B/V; the R/Y channel starts at byte 9. For RGBA, 3 offsets are stored, pointing to G,B, and A respectively; with the R channel starting at byte 13.

Each plane is packed with range coding with (fixed?) probabilities given in the beginning. Probabilities are coded with Fibonacci codes prefix for length and if code == 1 then the next Fibonacci code with zero probabilities count follow.

Fibonacci codes are constructed from the Fibonacci series 1,2,3,5,8,13,21,34 where each bits signals whether to add next value or not (i.e. first bit - add 1, second bit - add 2, fourth bit - add 5, etc) and '11' signal end of code:

  1 - 11
  2 - 011
  3 - 0011
  4 - 1011
  5 - 00011
  6 - 10011
  7 - 01011
  8 - 000011
 ...
 16 - 0010011
 32 - 00101011
 etc.
     

After plane decoding zero RLE may be applied. This RLE scheme takes escape length as argument - number of zeroes before run starts (1-3 zeroes only). So is escape length = 2 and two zeroes in sequence are met, read run length and output so much zeroes.

(TODO: describe compressed data layout; image prediction methods)

Uncompressed

Data encoding 1 is uncompressed data. The entire buffer after the type byte is copied into the output. This frame type is intended more for debugging than actual use.

Obsolete RGB

Decoding support only. The method for storing the compression header information and calculating the probability tables was changed in version 1.1.0.

Unaligned RGB24

Used for RGB24 frames with a width that is not a multiple of 4. This is used to distinguish between frames coded with pre-1.2.0 versions that did not correctly remove padding.

Solid Color Frames

When the value of byte 0 is 5, 6, or 9, this indicates that the frame is a solid RGB color. The value 5 indicates a solid greyscale color, and the entire frame should be set to the value of byte 1. A value of 6 indicates a solid RGB color, with bytes 1,2, and 3 representing the R, G, and B values that all pixels in the frame should be set to. A value of 9 indicates an solid RGBA color, and is handled the same as a solid RGB frame, except that byte 4 holds the alpha value that each pixel should be set to.

Reduced resolution frame

Identical to a YV12 frame except that the resolution must be upscaled by 2.