Archive for July, 2026

OMGperformance

Friday, July 10th, 2026

I use my own player for playing videos. It’s not very optimised (video frame decoded with VA-API gets downloaded to my own frame structure in main RAM, which gets uploaded to SDL texture and only then displayed—the proper way is to allocate EGL texture once and use it both for VA-API decoding and displaying; or maybe the same but Vulkan and semaphores all the way) but apparently playing back 25fps video even in that way takes less CPU than updating one line with play time in gnome-console at about 10fps.

I have a feeling something went wrong with the modern software…

A bit about next micro codec

Tuesday, July 7th, 2026

Some time ago I mentioned that I’d stumbled upon a QuickTime sample encoded on NeXT using MicroWavelet codec which was used only there. I also expressed a regret of it being completely lost to time. And what do you know, it’s yet another situation where I’d be glad to be proven wrong—and I was (and I am).

Apparently had I looked around for a bit longer, I would’ve discovered more samples and a decoder to boot. Apparently that decoder was a part of NeXTTime and not QuickTime, which is a completely different thing. And NeXTTime including that decoder could be found on OpenStep 4.x in particular.

While I have not written a decoder for it yet, I’ve figured out enough details to talk about it.

First of all, it’s a sort of several loosely-tied codecs (and I’m yet to figure out what makes it choose which decoding path to take). One of them is a simple wavelet codec with 8-bit coefficients and no additional compression, others are delta coding plus zero-run compression plus optional compression of that data. Optional compression may be either static Huffman coding (with trees stored in a separate file bundled with the decoder—a bit like ClearVideo did it) and an individual tree selected per frame, or it may be LZSS.

It’s nothing outstanding but still it’s a rather curious codec from a rather curious obscure platform (Display PostScript anyone?). And as a final fun fact, it’s internally called “harsh” with the functions being named e.g. harsh_decode_skip. Hopefully implementing a decoder for it would be mild and agreeable despite the naming.