Thats a great idea with the 32-bit output at a time.
August 19, 2010 at 5:31 PM
Hmm. I just wrote a long article on this and then as I was searching around for reference material, I discovered
that I already covered the topic in full detail :
cbloom rants 10-05-08 - 5 - Rant on New Arithmetic Coders cbloom rants 10-06-08 - 7 - Followup on the Russian Range Coder cbloom rants 10-08-08 - 3 - Arithmetic coders throw away accuracy in lots of little places
So, WTF I'm going insane. Anyway, here are some more links :
encode.ru : How fast should be a range coder ctxmodel.net : Context Modelling CiteSeerX : Arithmetic coding , Langdon 79 Sachin Garg : 64-bit Range Coding and Arithmetic Coding
One random thing I should note is that if you have 64 bit registers, you can let range go between 2^32 and 2^64 , and output 32 bits
at a time.
ADDENDUM : another random thing that occurs to me : if you're doing an fpaq0p-style sloppy binary arith coder where
range is allowed to get quite small, you can actually do a few encodes or decodes in a row without checking for
renormalization. What you would have to do is first do a *proper* renorm check that handles the underflow from
straddling the middle case (which it normally doesn't handle) so that you are sure you have >= 24 bits in your range.
Then, you can do several binary arithmetic codes, as long as the total probability shift is <= 24. For example, you
could do two codes with 12 bits of probability precision, or 3 with 8 bits. Then you check renorm again. Probably
the most sensible is doing two 12-bit precision codes, so you are able to do a renorm check once per two codes rather
than every code. Of course then you do have to handle carries.
"08-16-10 - Range Coder Revisited .. oh wait, nevermind"
1 Comment -
Thats a great idea with the 32-bit output at a time.
August 19, 2010 at 5:31 PM