Kostya's Boring Codec World

Today I (not really) want to talk about some weird coding methods employed by two codecs.

Monstrous Go2Meeting. To my very deep surprise its compression method 2 uses ELS coder, a curious binary arithmetic coder replacement. In essence it operates on fraction of bits (called jots by its autor) and uses something like state machine for model (i.e. depending on state and decoded jot value — 0 or 1 — move to one of two possible other states and subtract some state-defined value from input value). This implementation uses 36 jots per byte, has ladder with 174 rungs and operates on 24-bit state instead of 16-bit in the paper.

From a cursory glance on TAK it seems to be more or less ordinary lossless audio codec — i.e. LPC plus residue coding. The only peculiar thing is that residue coding. While other codecs use mostly adaptive coding, this one seems to employ fixed coding parameters for segments of residues and bitstream also contain parameter set indices for all these segments.

Scheme is rather simple: read predefined number of bits, if it’s not the escape value then reinterpret code as signed. For escape value get unary code, if it’s not equal to the secondary escape value then scale that value and reinterpret as signed. Else just read some additional number of bits, scale them and reinterpret as signed. Number of bits to read and escape values make those coding parameters (about 52 total).

Also even if it might provoke small flame war, I publicly say that I’d rather not see TAK supported in opensource. We have enough lossless codecs already, especially with their own containers. And they cover all possible uses already (don’t tell me about insignificantly higher compression ratio).

Some people wanted to have ProRes encoder in Libav so I wrote one. And from what I gather it even has one user (not me).

In case someone is interested here is the list of possible options:

• profile — selects ProRes profile to encode (proxy, lt, standard or hq)
• quant_mat — selects quantisation matrix from one of profiles (proxy, lt, standard or hq). If you don’t specify it, the matrix will be picked from default profile (or use auto to be really sure). There’s also default matrix which should give the highest quality (it’s default in the sense that when quantisation matrix is not provided in frame decoder defaults to this one).
• bits_per_mb — how many bits to give for coding one macroblock, different profiles use from 200 bits per macroblock to 2400, one can set it up to 8000.
• mbs_per_slice — how many macroblocks are there in slice, 1-8. Default value of eight should be good for almost all situations though.
• vendor — one can put custom vendor ID into frame like apl0 to claim it was produced by Apple encoder.
• qscale — set fixed quantiser

How to make it encode faster?

In default mode of operation encoder has to honour frame constraints (i.e. not producing frames with size bigger than defined) while still making output picture as good as possible.
If the frame contains lots of small details it’s harder to compress it and encoder spends more time in search for appropriate quantisers for each slice. Thus setting higher bits_per_mb limit will improve the speed.

Or if you don’t care about frame size constraints just set qscale parameter to something (I’d recommend 4) and see it encode MUCH faster.

Feel free to leave wishes for features in comments, hopefully I can implement it when I have time.

P.S. For proper 4444 profile support we need 10-bit YUV with alpha. When it’s in I can add that profile too.