Micro Wavelet: done

July 24th, 2026

So I’ve finally implemented NeXT Micro Wavelet decoder (and updated git bundles on the site while at it) and the codec turned out to be even more interesting than on the first glance.

The codec itself consists of three distinct phases: using delta prediction along with wavelet transform, packing results into 16-bit opcodes, and further packing the opcodes with Huffman or LZSS compression. There’s also a raw mode which simply transmits 8-bit deltas so it’s not particularly interesting.

First stage is probably where the codec name comes from: it works on 2×2 pixel blocks that get transformed into the difference from the previous block means (for each component) plus vertical and horizontal differences between block pixels (the same pair is used for all block components). In other words, not exactly full wavelet transform but not exactly no wavelet transform either.

Then the deltas get quantised to a small set of pre-defined values (13 values for red and blue, 15 values for green, 5 values for horizontal and vertical differences) and get packed into a single 16-bit value (that’s merely 63375 combinations out of 65536 possible, which leaves room for special opcodes). Normally one opcode represents a set of packed deltas but in theory it can hold “skip next N blocks” opcodes though I’ve not encountered a file with those.

After we got those opcodes it’s time to pack them (or write them as is). It can be done either with static Huffman coding or with LZSS that operates on 16-bit symbols. Huffman tree definitions are stored in the codec extradata after the main decoder configuration (which deserves its own mention and should get it below) and usually define about two thousand most common symbols, the rest are accessible via the special escape symbol.

Since I’ve mentioned decoder configuration, it needs to be described for being rather special too. First of all, it is not stored in the usual place (codec descriptor atom) but rather in the user data atom on the top level of track atoms. I actually had to modify a demuxer to handle it properly (and discoverd this fact by chance while looking at the end of MOV file and seeing it being suspiciously similar to the file with the default Huffman tree definition). This decoder configuration actually consists of two parts: fixed-size decoder state (essentially RAM data dumped into the file) and Huffman tree definitions. And the decoder configuration is flexible. Remember what I said above about the delta packing into 16-bit symbols? Well, it’s extensible—you can have different number of quantisation levels and delta values to be defined for each component, I simply decided not to support such rich features and stick to the hard-coded delta sets and packing scheme.

Overall, this codec reminded me about Duck TrueMotion 1 for some reason, maybe because of its custom delta tables. All things considered, that’s probably the most exotic codec I’ve ever worked on since it combines both unconventional coding methods (micro wavelets packing into mini-words) and the fact it comes from the rather obscure OS (at least it was ordinary M68K code). I probably had encountered and shall encounter more of crazy coding approaches but it’s not likely to be this combination of obscure technical approach and the obscure platform. As always, I’ll be glad to be proven wrong.

Posted in QuickTime, Various Video Codecs | No Comments »

Another weird format

July 17th, 2026

Just couple of years ago I had a small rant about German RLE-based codecs named *PEG. Recently I’ve discovered yet another pointless format called NPEG.

Unlike the rest it’s Polish, targets Amiga instead of DOS and it’s essentially MPEG-1 frames stored in IFF. Considering that it appeared around 1998, NP1 is the original MP4 format (if you ignore MPEG-1 in MOV of course).

Currently I have no desire to implement support of it but maybe one day I’ll really have nothing better to do and add MPEG-1 support (with various exotic containers) to NihAV. Though I hope such day will never come.

Posted in Various Video Codecs | No Comments »

OMGperformance

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…

Posted in Useless Rants | 4 Comments »

A bit about next micro codec

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.

Posted in QuickTime, Various Video Codecs | No Comments »

TWV: unsupported formats

June 25th, 2026

While the weather is stewing here and there’s no desire to do anything, I suppose this is a good occasion to talk about two formats with the same extension that I’m not going to support.

The first TWV format comes from Reality Pump games like Knightshift and World War III: Black Gold. It is not a particularly complex codec but the fact that it’s simplified version of interlaced MPEG-2 or MPEG-4 with an additional layer of headerless deflate compression makes me not want to work on it at all.

The other TWV format comes from Québec and I’ve encountered it in Le Logiciel de Finances Personnel and (mostly with TMV extension) in the game Music Chase. I’ve written about it some time ago, essentially it is QuickTime MOV format with the annoying quirks like all values being little-endian, some additional fields inserted (I suspect that 1-byte version field and 3-byte flags field combination got expanded into two 4-byte fields), and it also uses custom handlers for both audio and video tracks (yes, even pure audio files contain a video track with dummy 17-byte frames). I tried to read the binary specification for the video decompressor but quickly got lost in code for Windows 3.x that Ghidra refused to decompile. The same applies to their special BMP compression (in TBP files).

Hopefully somebody else can fare better but I don’t expect to see these formats supported even in librempeg.

Posted in QuickTime, Various Video Codecs | 4 Comments »

A new/old video coding scheme

June 19th, 2026

Now that AV2 has officially been released it’s time to remind that these codec advances are not for free. Here it is claimed that AV2 offers about 25% improvements in compression efficiency compared to AV1 with decoding being five times slower (and that’s for an extremely optimised decoder; no idea how much slower encoding is).

Back in the day I proposed to go full AI with the codec design but it was not a fully serious idea, here I’d like to propose something more realistic that would use “AI” hardware that we should have plenty of by now—and with no AVn codecs in mind.

Read the rest of this entry »

Posted in Useless Rants, Various Video Codecs | 14 Comments »

#chemicalexperiments — Saumagen

June 15th, 2026

I think it’s time to talk about the würst aspect of German life.

It is a stereotype that Germans love sausages, and it seems this stereotype has some background after all. What’s more, as I learned from one fountain in Kandel, the nearby area of Rhineland Palatinate was known as the Cattle Belt—and you can guess what they made out of that cattle. One of those specialities is called Saumagen or “pig’s stomach”, a sausage made by filling the namesake with meat, diced potatoes, spices and boiling it (some people prefer to fry it afterwards anyway, making it to spiritually resemble haggis even more despite sheep not being involved at all).

Initially I learned about it when I bought various kinds of tinned sausage from Landau at the local supermarket (yes, it is common here to sell sausage tinned and even rural butcheries produce it), but in the recent years with the spread of vending machines in rural areas offering local goods I had a chance of trying more varieties of it (those machines work every day while almost everything is closed on Sundays—exactly when I have time to travel around). So I’ll describe what varieties of saumagen I’ve seen before mentioning other curious sausage-related things.

Weisenheim am Sand is the only place (so far) offering saumagen in slices (vacuum-packed) in addition to tins. It’s nice but it had a bit too much mustard seeds (or maybe it was marjoram) to my taste.

Kirchheimbolanden offers variety with the most ingredients: it’s the only one I’ve encountered that added carrots as well. Also it has the other variety of it like in St Martin.

Speaking on which, St Martin had the best saumagen to my taste. In addition to the regular version there’s another one with chestnuts instead of potatoes. Even the fact that they add a bit of beef to it does not spoil it at all. The funniest unrelated fact is that I bought it from the shop that was open on Good Friday (it is a rare occasion when something is open on public holiday, especially on public Catholic holiday in former part of Bavaria).

Maybe I’ve seen and tried it elsewhere but those variations didn’t leave an impression. Unlike the one variation that I’ve not tried and yet it left an impression: I’ve seen this exotic dish being advertised at some restaurant in Lorsch (which is a part of Hessen and lies on the other side of the Rhine).

There are other interesting mentions (with my health I should not eat meat much or often—so I don’t, and probably there are a lot of other things that I’ve never seen; but that’s for other people to talk about). For example, in Bavaria it is common to have a version of common dish made from liver (hence my test for maultaschen not being Swabish—otherwise there would be the ones made from liver in Bavaria like it happens with spätzle). Though they have Leberkäse, literally “liver-cheese”, which contains neither.

And in Württemberg I’ve encountered at least twice Bologna sausage with boiled eggs (it makes me think of Scotland for some reason once again).

For the traditional sausages I prefer käsekrainer which are available everywhere in varying thicknesses and lengths. The best ones I’ve ever tried came from Sasbachwalden (which is worth visiting for other reasons, it’s one of the most scenic places I’ve ever seen).

That’s the story with the sausages: you pull one link and another one comes after it. I started with one specific local variety of sausage, overcame a desire to talk about local vending machines that can sell e.g. ice cream instead (not something you’d expect to see in a random village), still ended mentioning some bits of geography and local customs as well as other food articles. More talented person could write a book about German history viewed through a sausage ring (and it would be a very entertaining read!), but all I can manage is this pathetic post.

P.S. And from a small biased review the most impressively decorated butcher shops I’ve seen were in Bad Kreuznach, Ingelheim am Rhein and Durbach (the one near Offenburg).

Posted in #chemicalexperiments | No Comments »

MOVing Puzzles

June 14th, 2026

Mostly because of the weather I have not been in mood to work on anything serious for weeks, but here is something rather interesting.

Apparently there are some CD-ROMs represented on discmaster titled “Moving Puzzle: …” that have some .mv files (inside media.pak archive) that supposedly give motion to those puzzles. And of course somebody had to look at the format.

Obviously the format was inspired by QuickTime as it has the header with all those chunks defining per-track data including e.g. sample-to-chunk mapping. There are two main differences though: the format is flat as first you have header size and header chunks following each other without any nesting (so when you encounter the second track header chunk the following chunks will belong to this new track); and the data is little-endian there, both numbers and tags (e.g. “ssiz” which is sample sizes chunk is written as “ziss” instead, same for e.g. codec IDs). Luckily I could ignore most of it as the data seems to be stored without gaps, so reading palette, then seeking to the first video chunk and reading individual samples(frames) from there works fine.

And it has its own two codecs, RLE and LZSS. RLE has two modes, both coded the same but inter mode storing the difference from the previous frame (not even XOR, simple subtraction by modulo). LZSS is not the usual flavour either. Unlike the most widespread scheme of “read 8/16/32-bit flags, treat the following bytes until next flags as either literals or packed 16-bit LZ offset+copy length combination” here it is a continuous bitstream with offset and length bits being signalled in the bitstream header and offset zero being used to skip decoded data (since you decode to the frame buffer, it leaves some bytes of it unchanged). Nothing groundbreaking but you most implementations hardly make any changes from the original LZSS.C and right now I can only think of JAM format which implemented LZSS with copying from the reference picture.

IMO this is an over-engineered system but that’s what makes it interesting to look at.

Posted in Game Video | No Comments »

AI-coholism

May 29th, 2026

With this matter, I hope I actually shan’t have more to write about. But this thought needed to be written out (only if to unload it from my head).

For some reason the current state of affairs around “AI” reminds me a lot of alcohol. Mind you, it’s a useful substance (as a solvent or a disinfectant), some people may even use it in recreational purposes or to deal with stress—but there are always some people abusing it, often for no good reason, and giving bad name to it all. Also there were countries whose budget was largely dependent on alcohol over-consumption but that’s less important here.

The situation with “AI” assistants looks entirely familiar: some people use it responsibly and even achieve useful results with it, but it’s usually other people (a loud but hopefully still minority) who abuse such tools to the point they get high with imaginary power and behave themselves as typical drunks: some boast how much they can consume (tokens or pints of beer), some vomit uncontrollably (you can see the results on GitHub—when it is still up of course), some suffer from neuro-toxic effects (and can’t move or code straight any longer without an external support), some lose all internal restraints (there’s little difference between alcoholics raising ruckus because their favourite liquor store is closed when they want to get a drink and AIcoholics trying to push slop to some project without caring what the change does and why the project in question doesn’t want to accept it). And occasionally you can see the entertaining stunts that would cause normal person a serious damage (like falling from a third floor or deleting a production database) but with a person in question not realising that at all.

Hopefully the situation with “AI” will mature and normalise so that the technology abusers will be shamed for their actions and become an exception instead of current “sport fans right after the match” vibe.

Posted in Useless Rants | 2 Comments »

We have FLI at home

May 29th, 2026

Recently I’ve released na_eofdec, a tool for decoding exotic and/or obscure formats. That release included F16 format support, but recently I’ve REd another one (PC Animate Plus / 3D WorkShop animation) and there’s yet another one waiting in the queue (Reflections animation). What unites them all is that they all employ simple compression schemes (mostly RLE-based) and (beside F16) they all have a 3D modelling program associated with them. And I’ve REd these formats by investigating the file format, they’re that simple.

F16 posed itself as “FLI but 16-bit” and it looks like its creators have failed to build an ecosystem out of it. I have encountered merely two demo samples at discmaster and nothing else. From technical point of view it’s either uncompressed intra frames or the rather familiar FLI delta compression scheme with its number of skip/run opcodes per line, just with small variations.

PC Animate Plus is more interesting as it has 4-, 8- and 16-bit content compressed, at least two format versions and several compression schemes. Plus it has some additional chunks for complex operations and even metadata telling e.g. which Voc file to play along. Intra frames are RLE-compressed, inter frames usually employ FLI delta compression (with small changes of course) but there’s another mode consisting of offsets and chunks of data to update. Another interesting thing is that it does not replace old pixels but XORs them with new data instead (maybe it comes from an alternative universe where 80×86 had REP XORMOVSB instruction).

And there’s Reflections animation. While I haven’t written a decoder for it yet, I can describe it already. I’m aware of three samples with rather uncommon 320×256 resolution and big-endian format. First frame is uncompressed, the rest seems to be simply “skip N 32-bit words, update M 32-bit words”. Writing a decoder for it should not be that hard… An update from the next day: it’s simple RLE with opcodes being skip/repeat/copy but the actual data is stored in 4-pixel columns format, so e.g. copying 8 pixel quads will result in 4×8 rectangle.

Individually the formats are nothing to write about but together they form a group of FLI clones that poses some interest. Now that I’m done with MVS it’s either extending QuickTime support in NihAV or REing obscure formats, hopefully it will give me more material for my writing.

Posted in Various Video Codecs | No Comments »

« Older Entries