Okay, now it should be the last post about TM2X.
It’s hard to believe but looks like there were at least five versions of this codec that can be distinguished by the chunk ID where frame information is stored (I have decoder for versions 1-5 and all known samples are version 4). So in version 5 they’ve added coding of motion vectors for 8×8 blocks in various forms including quadtree (and that’s what confused me). Looks like there are tile dimensions stored in configuration chunk (0xA0000109) and codec operates on those.
Again, looks like decoder first calls a function to determine what to do with a row of blocks and then corresponding functions decoding (sub)block data. And I was confused by those too—some of the functions read luma and chroma, some functions read only chroma and some read luma, chroma and two other unidentified values of different types (so it’s not a motion vector). They always have 2 luma samples (if present) and 1/2/4/8 chroma samples. Or is it the other way round with two chroma samples and 1-8 luma samples?
What the Duck, On2, couldn’t you opensource TR20 and TM2X/TM2A along with TM1, TM2 and TM VP3 (and they were all in the same package, mind you)?
In any case I’ll try to forget it again, there’s still VP4 (aka AOM codec -5).
I still remember that the Duck TM1 source code made reference to some sort of sprite-based compression scheme. I wonder if that ever made it into the wild?
VP4 = AOM codec -6
AOM codec 1 is VP 9 for now – says https://aomedia.googlesource.com/aom/+/81e552690ead9a29a1559ee5d2dcb6fad44d9ee8
No matter how I do math I don’t get -6 for VP4 (-4 on the other hoof…).
Well, AOM codec has to start somewhere; over VP9, it already has Daala’s deringing filter, and there’s effort to add Daala’s vector quantization scheme; Daala’s entropy coder also might end up there.