If it looks that I’m not doing anything, that’s about right. Nevertheless I’d like to discuss two exotic formats that I’d like to write decoders for.
The first one is unlike most of the video codecs I’ve seen so far. For starters, it uses fractal compression. Not surprising since it comes from Iterated Systems. And unlike later ClearVideo, it is really a fractal codec. From what I see, it works exactly like the textbook example of the fractal compression: split video into small fixed-size blocks, search for a domain block, apply simple affine transform on scaled-down version of it plus brightness scaling and output the result. There are additional possible operations like leaving blocks unchanged or reading raw data for a block. Since this works only for the greyscale, frame is stored in YUV420 format, planes coded sequentially. Unfortunately since the binary specification is mixed 16/32-bit VfW driver that Ghidra can’t decompile properly, the work on it goes at glacial speed.
The other codec is like the previous one but it has its own container format and DOS player. It comes from TMM—not The Multimedia Mike but rather the company known for RLE-based PH Video format. I don’t see mentions of Iterated Systems in the binary specification, but considering how similar this FRAC codec is to theirs (it uses the same bitstream format with the same opcode meanings and the same assembly instructions) I expect they’ve licensed it from Iterated Systems.
So hopefully when I actually finish it I’ll have two decoders for the price of one.
Why are fractals not more used today in codecs? The CPUs are fast enough today for it?
Probably for the same reason as wavelets: it may be decent-looking picture at low bitrate but it does not compete that good when you want more details; and then there’s the whole question of handling motion compensation.
I suspect that actually it will converge by making motion compensation to be a lot like fractal compression—it’s halfway there already (copying blocks is here, affine transforms are somewhat here, scaling is coming next probably), the only thing that is radically different is using reference picture as the source instead of the encoded image itself.