Author Archive

The age of stupid greed?

Saturday, April 4th, 2026

Of course neither stupidity nor greed (nor a combination of both) has been scarce at any point of human history, but in these days it feels like the main driving force behind various decisions at all possible scales, from individuals to the countries.

Naturally, despite having the common mechanics (some entity pursuing short-term gains while destroying the prospect of long-term gains) there are different flavours of it and I’ll try to review some of those.

First of all there is something that can be called goodwill monetisation. In this case somebody tries to convert existing reputation, connections and such for instant financial gain even if that leads to ruining them (and the profit they generated) for rather meagre compensation. The simplest example is any company selling its customer base data to e.g. advertisers (large corporations can get off with it by being monopolists and not having much reputation to lose in the first place). But the biggest beautifullest example of it is USA as a state. Back in the day I wrote a post about it that USA got as successful as it was until quite recently because it created a field and rules for everybody to play by. But certain somebody decided that USA is too important so if it will demand money from other trade participants just because and they will comply—not understanding that the trade was flowing to the USA because it was an attractive country for that and his decisions make it less attractive country and in the future others would think twice before doing any business with it (a small personal example: I haven’t bought anything USian in 2025 even if I had done that before occasionally and I’m not sure if I’ll ever consider it again). Similar acts regarding other things (like trying to leverage NATO to act as its personal army as well as buying more USian weapons just because; all while demonstrating how unwise it is to rely on them or—as Switzerland has recently learned—even to get what you paid for). I’m pretty sure more examples will keep providing themselves, all I can say that all trust-based systems would have the same effect (e.g. try to cash in 10% of total company stock or “crypto”coins emission in a short time and their price will drop even during such transactions and probably will remain low for a long time after).

Then there’s management. By that I mean not merely a swear-word (equivalent to being stupid and greedy sociopaths) but the acts of destroying company in the long term for short-term benefits (resulting in bonus for the manager, the only important thing here). You know, outsourcing production overseas, laying off staff just to show certain level of expenses cut (even if you have to hire those people back next quarter and not all of them will agree to come back), rushing production and cutting corners and so on and so on. Probably you can point at any large company for that but the best example IMO is Boeing with its catchy slogan “if it’s Boeing I’m not going”. Usually the companies have some robustness so when the aftermath of management starts to show it’s too late to save them (of course there are small miracles like Lou Gerstner and RedHat but in general don’t bet on it). I heard that vestments and options are supposed to fix that but I suspect it won’t work as good while there are no repercussions for doing badly (i.e. if you screwed up your current company you’ll still get your precious metal parachute and get employed by another company—unless you need a presidential pardon to remain in business of course).

There’s also general stupidity best illustrated by this joke: Security arrested a man who tried to smuggle uranium in his underpants. They ask him why did he do that and does he realise he won’t have any children now? To that he replied that he’d get enough money to leave to his grandchildren. This case is nothing new and happens every day to many individuals (you probably can name a couple of examples yourself). And if you wonder how it’s different from the previous two cases, it’s the nuances: in goodwill monetisation you kill the hen laying eggs for making a pillow (not even a soup!), management usually destroys somebody else’s property for their personal gains, here it is exercising a plan without thinking about consequences while those consequences backfire and make the original goal unachievable.

Another case can be called “a bull in a china shop”. Here some entity is so envious about money going past them that it makes a desperate grab for them, making things worse for everybody. Since this is a blog (occasionally) about multimedia, the most appropriate example would be codec licensing. The idea was simple: a committee creates a codec from the best technologies submitted by different entities (companies, universities, Fraunhofer-Gesellschaft etc), then everybody enjoys the best technology for a reasonable fee, which is used to pay the original creators—everybody wins. But then not just the patent holders involved in the codec creation got stupid greedy but completely unrelated entities as well, so now we have at least three patent pools for H.EVC and nobody is willing to use VVC at all (maybe except Brazil). So of course it’s the best time to raise fees on H.264.

And of course it gets better! The natural reaction to such thing is to move away from patented stuff—which Alliance for Open Media did. So the predators moved after them. Even before AOMedia there was VP8 and Nokia with its famous patent that apparently covered any modern video codec. And there’s D*lby, definitely not a nice company (fun fact: unless I’m mistaken, when this originally British company moved to USA, D*lby Labs Licensing Corp got incorporated earlier than D*lby Labs Inc.). For a long time it was known for its cinematic equipment and, more importantly, for charging significantly more money for its ATSC A/52B codec than others for their codecs combined (I don’t have official numbers of course but I heard that while H.264+AAC decoding cost ten cents or less per unit, for ETSI 102 366 you had to pay over a dollar per unit; plus a custom license deal—in other words, it’s better not to deal with their stuff at all). With their successor codec not being that popular (despite so many wonderful DRC modes!), D*lby Vision not being too widespread either, their only winning move was apparently to go after the competition. So first they sued two companies here in Germany for using AOMedia OACv0 (aka Opus) which allegedly violates their patents, later they went after other companies for using AV1 which allegedly violates their patents (AOMedia definitely needs to produce more stuff to get sued after, IAMF might be not enough). I don’t know if D*lby wants a one-time ransompayment, or a constant stream of royalties for a free stuff (don’t ask me how it would work, they don’t care either), or to be bought by large AOMedia member(s). All I can say is that this situation definitely makes it worse for everybody not even directly involved in it.

If you wonder if there are other types of stupid greediness being practiced, there definitely are—idiots can be very inventive after all. Meanwhile the (dis)honorary mention goes to “AI” companies for blending all of those flavours of stupid greed into one large slop.

What a time to be alive!

(Ir)regular NihAV news

Monday, March 30th, 2026

Here’s another portion of news about what I’ve been doing in last couple of weeks. Hopefully I’ll be able to write about fruity MVS soon.

While most of what I did is not worth mentioning, there are some bits I find funny or curious enough to share.

First of all, I’ve added VAXL and (Clari)SSA decoding support to na_eofdec (just some more and there will be enough formats for 0.1.0 release). And I actually added them mostly to test an IFF parser (derived from my AVI parser and enhanced). The idea is simple: just point it to the data needed to be parsed and provide chunk handlers and it should do the trick. The main enhancement is also providing a condition when to stop—at the end, on any unknown chunk, before some pre-defined chunk, or right after such chunk has been parsed. This way I can control parsing process without relying too much on some special callbacks or states. For example, in VAXL that means I parse header by expecting VXHD chunk and nothing else. The rest of VAXL consists of time code, palette, image data, and audio samples chunks; there I simply stop after BMAP chunk and output reconstructed frame (and audio if present). In SSA (IFF variant, I added FEE one too for completeness sake) each frame is wrapped into FORM DLTA list so there I just parse sub-chunks ignoring unknown ones.

Then I’ve finally had another look at TCA and improved my decoder, going from less than half of samples I had being supported to virtually all of them. While I presumed that video is always compressed with LZW, in reality it also has RLE and raw modes. RLE mode is rather curious at that as it codes run+mode as 00 00 xx yy zz, 00 xx yy or xx number (i.e. if first one or two bytes are zero, read one or two bytes of the number too) with low bit signalling run or skip and the rest being its length (e.g. 55 means skip 42 bytes while 00 01 00 01 means repeating 01 128 times). But since the format is next to impossible to detect statically (no magic constants in the header, so you’d better check packet structure instead), it’ll remain a useless curiosity—just like I love it.

And most of the time I spent on writing MOV muxer. Since I’ve written one for na_eofdec already (raw output only) I had some base to start off at least. Of course it’s wonky and even copying data may or may not work depending on your luck, at least now I have a format to output variable framerate content losslessly (previously the only alternative for VFR content in NihAV was to encode data with RealVideo 4 and Cook). At least now, after all possible enhancements, I can either re-mux old-style MOV into a new one (and the output may actually be playable) or use nihav-encoder -i input.mov -o output.mov --profile raw to decode some more exotic format not supported by anything else (like MoviePak in MacBinary MOV) to a raw format that (hopefully) more tools can understand. I can also use my Cinepak or Indeo 3 encoders there (and Truemotion 1 too in the future just for lulz) and I should probably write encoders for other common QT codecs (even if there are other implementations, up to SVQ1 by The Multimedia Mike). This should keep me entertained for a while. And who knows, maybe it will serve as a base for MP4 muxer if the need for one arises.

That’s it for now, hopefully I’ll have more to write about later.

Some words about RAD Audio

Saturday, March 21st, 2026

So I tried to look at RAD Audio. The main problem is that its binary specification is unclear (i.e. decompilers have problems with it) and it’s not something easily approachable without one.

Anyway, from what I managed to figure out, it’s more or less equivalent to AAC-LC except being less extensible (and thus slightly saner).

While AAC-LC gets packed into some container format with excessive features (even something like ADTS), here packet header combines all information: first byte is packet header byte (0x55) followed by a byte or two of packet flags (i.e. what features are enabled and if following number fields are 8- or 16-bit values), packet size (8- or 16-bit), two other numbers with unknown meaning (also 8- or 16-bit each, they might be related to the frame coding parameters like number of subbands in use).

Frame structure from a quick glance looks very AAC-LC as well, with active use of Huffman codebooks for coding most of the data (initially I found just two codebooks, apparently the actual number is closer to twenty). And there are tables describing coding modes for four principal sampling frequencies (24/32/44/48 kHz) and two coding modes (normal with mixed short and long frames, and short frames only mode; normal mode is remarkable for having a special frequency table with the same number of bands as for short frame but designed for a long frame—I suppose it’s for the transition frames).

Overall, it’s a rather simple audio codec in a rather simple audio format (and for that reason I’m not interested to look at it further—figuring out details is tedious and serves no real purpose for me). And for the next thing, there’s apparently some fruity codec used in proprietary VNC protocol extension that’s worth looking at…

More boring stuff in NihAV

Thursday, March 12th, 2026

Since the last time I’ve done some more boring stuff for NihAV, more precisely 10-bit H.264 decoder and extended MOV support.

The former is more or less straightforward but it made me regret Rust lack of text-level macro processing. The problem is generating almost identical code for various combinations of bitdepths that differ only by the clipping range and function name suffixes. Probably it can be solved with proc macros but that’s a hole I’m unwilling to jump into. Also supporting both 8- and 16-bit decoding in one module is annoying, so I ended up just putting them next to each other and selecting one for the current mode of operation. This also uncovered the fact that my scaler did not handle high-depth YUV in the most cases, so I had to fix it too. And the ironic thing is that I don’t have enough content to watch in that format (and a couple of sample files I have are Matroska with FLAC audio, which can’t be remuxed to MP4, so there’s that).

In other rather equally useless things, I’ve finally made a MOV muxer for na_eofdec. Of course it’s a simplified one, supporting only raw video and audio tracks, but even that was annoying to support properly (I’m still not sure if I do support it properly). At least when the bitterness passes I should be able to make a MOV muxer for NihAV (and who knows, maybe even implement some QT encoders to exercise it).

But that’s not all regarding MOV. In a recent post I mentioned the oldest known MOV flavours. Finally I’ve managed to extend my MOV demuxer to support beta version of it (it’s still MOV but with a few different details here and there) while alpha version was easier to support in a different demuxer written from scratch. If you’re curious, those files are short clips (about 15 seconds usually) compressed with QT RLE demonstrating some features of upcoming System 7 in rather symbolic form. Here’s a GIF of virtual memory feature presentation.

That’s about it for now, I hope to do more exciting things next. For instance, add some Amiga formats to na_eofdec. And most importantly, Paul told me about new RAD Audio codec which I still have to look at thoroughly. From a first glance while audio in Bink is a lot like MPEG Audio Layer II (i.e. simply quantise and write coefficients with a fixed amount of bits), this new codec is more akin to AAC LC as it apparently has long/short frames division and (at least two) Huffman tables for coefficients. Another change is that Bink audio was stored in simple container formats with fixed structure, new format looks more like an elementary stream with as few bits as possible spent on coding different fields. Let’s see how it turns out…

A word about some JPEG-based codecs

Wednesday, March 4th, 2026

As I mentioned previously, I don’t want to work on game codecs for a while, so I picked other stuff instead. For instance, I’ve fixed a bug in my Indeo 3 encoder (which nobody uses, myself included), refactored some NihAV code and added a couple of decoders.

First, there is PDQ2 decoder. It actually turned out to be slightly more interesting than I expected as there’s a version of the codec for Saturn version of the game (it’s not that different yet somewhat different nevertheless).

Then I’ve finally managed to figure out MoviePak. After locating a decompressor binary and trying to disassemble it as raw M68k code I could locate enough code and data to figure out that since it uses JPEG codebooks it’s likely to be based on JPEG. And after learning a bit more about how it works and NOPing out A-line _StripAddress calls (that was the most interesting part actually—you can’t find it without knowing terminology and even then just barely; I was lucky to try searching for information about 68881, learning terminology and finally finding a reference of Macintosh Toolbox calls) I managed to make Ghidra happy enough to produce a usable decompilation. After that it was just a question of re-using JPEG decoder with a slightly different header format, which finally made me do a refactoring of JPEG decoding.

And since I’ve factored out common JPEG decoding support for MoviePak, Radius Studio and actual motion JPEG decoder, I decided to add a video codec for effects used in proDAD Adorage video editor (its FOURCC is pDAD, quite surprisingly). This one could be reverse engineered just by looking at the frame data. Each frame consists of 20-byte header, JPEG image plus alpha channel coded as PNG or JPEG. Since I have not bothered to write a motion PNG decoder (it’s very uncommon after all and I’m not NIHing image library—at least not yet), I decode just the first part. Maybe I’ll add a PNG decoder support and re-visit this decoder for proper alpha support, but for now this seems unlikely.

I’ll keep working on some boring stuff nobody cares about but maybe I’ll have a codec or two to write about as well.

Four years

Tuesday, February 24th, 2026

It’s been four full years of/since February 24, 2022 when russian reich openly invaded Ukraine with boisterous claims that they’ll take Kyiv in three days and the rest of territory in a week. They wanted small victorious special military operation but something went wrong. Despite having much larger territory, population, economy, more allies and being prepared for it they still failed to achieve their goals—and by those I mean their real goals of occupying and fully annihilating Ukraine, using its resources (people included) to continue a war on other territories; their declared goals change depending on the situation at the frontline (or as one of them said, the goal of it will be formulated when it’s over).

Nobody believed that Ukraine would stand and yet it does despite all the help russia receives from its allies like Belarus, China, DPRK, Iran, and, apparently, USA. The situation is far from being good, with russian attacks targeting almost exclusively civilian targets, currently trying to leave Ukrainian cities without electricity and heating during the extremely cold weather. And yet Ukraine stands.

At least this war exposed some things: that russians are no people (not because of some biological differences, mind you, they lack moral qualities that make humans humans and not just slightly smarter primates), that their money (or natural resources) buy affection indeed (often enough to close eyes to russian transgressions and atrocities—there are enough countries and international organisations serving as an example), and that it’s apparently contagious (just look at the USA that resembles russia even more with each passing day).

I’m not optimistic about the future but I really hope that Ukraine will stand and russia will fall down (despite efforts of USA to preserve it—not for the first time too). Only this way we’ll get some peace—until people forget and let another bully run unopposed.

Some words about the oldest QuickTime

Thursday, February 19th, 2026

Since apparently discmaster.textfiles.com ran out of space (because storage is not cheap now thanks to “AI” companies), I have no new formats to be distracted with and have to resort to looking at the old ones.

As we all know, A**le single-handedly invented multimedia and the existence of IFF ANIM (that pre-dates it by a couple of years) should not confuse you. From what I could find, the earliest QuickTime samples can be found on Apple Reference & Presentation Library 8 CD-ROM that was intended for demonstration but not for the consumers. That disc actually contains three flavours of QT MOV: ordinary MOVs that can be decoded without problems, slightly older MOV that looks almost the same but has slightly different format (and features version -1 both in the header and in the metadata strings) and some extremely old files that do not correspond to the usual MOV structure. Those apparently come from the alpha version of QuickTime around year 1990 when it was still known by its code-name after USian artist of Ukrainian origin.

The first glaring difference is that atoms are not strictly nested but may contain some data beforehand. Essentially all atoms that normally have special header atoms have it before the rest. So instead of (pardon my S-expressions)

(moov (mvhd (trak tkhd (mdia mdhd (minf …))))

there is

(moov [moov header data] (trak [trak header data] (mdia [mdia header data] [all codec description data])))

Data structure is flatter too. In release QT version data for the individual tracks is grouped into chunks, so the header describes both the chunks and what tracks use what chunks (and what are frame sizes in the chunk). Here frames are stored as (offset, size) pairs.

From the accompanying decoder I can see it supported raw video, RLE and motion JPEG at the time—fancy vector quantisation codecs came later.

I hope to support it one day but there’s no hurry. Currently I’m more or less done improving NihAV tools and want to add some practical demuxers, muxers (and maybe even impractical encoders like for Indeo 4 or RedHat Ultimotion). And there’s na_eofdec still waiting to collect enough supported formats for its first release (tangential fun fact: recently I’ve added support for Electric Image format there which is mostly a simple RLE but its frames apparently have timestamps in floating-point format like 0.266 or 0.5).

P.S. I’ve also discovered MoviePak QT codec which looks like JPEG variant. Maybe one day when I’ll have nothing better to do I’ll look closer at it, but for now I have no desire to reverse engineer M68k code in unknown format.

More codecs to look at

Wednesday, February 11th, 2026

Here’s a list of video codecs I found with the help of discmaster.textfiles.com (mostly by looking for .inf files with “vidc” in them). Maybe I’ll look at them one day, maybe somebody will beat me to it. In either case, it’s a nice reminder for myself.

  • CSMX.dll—reportedly used for CSM0 codec, was bundled with some player, no known samples. Considering its small size it’s likely to be either raw YUV format or lossless codec;
  • d3dgearcodec.dll—D3DGear lossless codec;
  • elsaeqkx.dll—some Elsa quick codec;
  • Esdll.dll—bundled with the same player, the strings inside it hint on it being an unholy mix of ZIP and MELP-based speech codec;
  • ICS422.DRVS422 or SuperMatch YUV 4:2:2 codec (I suspect it’s raw YUV);
  • ICSMS0.DRVSMS0 or SuperMatch VideoSpigot codec (from SuperMac, later bought by Radius);
  • MCTCOD.DRV—MCTPlus Draw driver, supposedly offering 2:1 compression and has a bunch of FOURCCs registered to it: DRAW, MC16, MC24, MR16, MR24, MY16, MY24
  • MyFlashZip0.axMFZ0 lossless codec. Looks like ordinary deflate wrapper really;
  • NTCodec.dll—NewTek nt00 codec (I expect lossless or an intermediate codec). Looks like a simple fixed-fields packing;
  • RGBACodec.dll—apparently Lightworks lossless RGBA codec. Simple RLE inside;
  • Sx73p32.dll—Lucent Technologies SX7300P speech codec;
  • TRICODC.DRV—Trident draw codec with a bunch of compressed RGB and YUV formats: rtc3, rtc5, rtc6, ty0n, ty2d, ty2n, ty2c, r0y1… Compressed in this context means packed using fixed-length bitfields;
  • UCLZSS.DRV—Ulead LZSS codec aka uclz (obviously a simple lossless codec). As expected, it’s yuyv data compressed with LZSS;
  • UCYUVC.DRV—Ulead compressed YUV 411 aka yuvc. Apparently it’s just 8/12/16-bpp YUV (fixed packing scheme, and 16-bit is simply YUYV/YUY2 and such);
  • V422.DRV—Vitec Multimedia V422. Most likely simply raw YUV;
  • V655.DRV—Vitec Multimedia V655 (I’ll venture a guess this means 6-bit luma and 5-bit chroma instead of improbable YUV 6:5:5 subsampling);
  • VDCT.DRV—Vitec Multimedia VDCT.

Oh, and I’ve also found Eloquent elvid32.dll for EL02 FOURCC but it’s different since it has samples and it’s yet another H.263 rip-off.

That’s it for now, I’ll talk about FLAC video some other time.

Random NihAV news

Sunday, February 8th, 2026

As I mentioned previously, after making 0.5.0 na_game_tool release I’d rather work on something else for a change (if at all), so here are some bits about what I’ve been doing since:

  • first of all, I’ve implemented support for AV, a Polished AVI format. By that I mean the format comes apparently from a Polish company and it’s simplified remux of AVI data: first there’s BITMAPINFOHEADER (and optionally palette) followed by video stream header (starting with the familiar vids tag), then there may be WAVEFORMAT structure with auds stream header, then you have table of contents (video and audio frame sizes plus flags) followed by video and audio chunks. The format was trivial to guess and I’ve added support for it because why not;
  • I’ve also finally implemented functions for reading arrays of integers. First I’ve introduced them to na_game_tool and tried them in some decoders, and then ported them to the main NihAV codebase. The idea behind it is that reading data directly into destination array (with optional byte-swapping) is faster than reading data, re-interpreting it as an integer and finally copying it into the destination buffer. I had a specific version of it implemented in MP4 demuxer already (because otherwise opening a 2-3 hour long video would cause a noticeable delay) but overall it’s nicer to have just one call instead of a loop;
  • in other things, I’ve re-started na_eofdec development using the current na_game_tool codebase. That does not mean I’m starting developing it (or going to do so in the nearest feature) but at least when I eventually get to it, I can add some archive extraction modules as well. Beside that it should be a sandbox for testing MOV muxer that I want to write sooner or later (kinda like OpenDML AVI muxer in NihAV is a backport of one from na_game_tool). Of course it would need to get a couple more formats to test it on but I’m not in a hurry;
  • speaking of MOV, I’ve improved support for MOV in MacBinary II. So far I’ve seen four flavours of it: essentially flat MOV with MacBin header, MOV with mdat box in data fork and moov atom in resource fork, the same but data fork containing mdat contents without size and tag, and even older format (with samples from 1990) with much flatter structure (i.e. lots of nesting chunks are not present at all). The first three are detected and handled more or less fine now, I’ll try to support it even if as a historical curiosity;
  • there was one major code refactoring in NihAV, namely I’ve put demuxing handling code into a new nihav_hlblocks crate and made all my tools use it instead of dragging local copies of it. If you wonder why this was necessary, that’s because you can have normal demuxers (that return full packets for the streams) as well as raw stream demuxers (that return pieces of data belonging to a stream and you need to form full packet using a packetiser). And of course you can have simply raw streams like MP3 that needs a packetiser but no demuxer. That’s why I’ve made a DemuxerObject (yes, very original name) that encapsulates them all and represents all of them as a normal demuxer;
  • and finally I’ve discovered that I can call SDL_UpdateYUVTexture instead of copying frame data into the texture manually. And then I discovered that it did not work with the time display (because it also wrote to the texture directly in presumption that it will update some pixels on the frame; there is a note in the documentation telling not to do so but it worked by chance before). So I’ve changed it to render a separate small RGBA texture and blit it over the frame instead—like it should’ve been done from the start. I somewhat wonder when I’ll have to adapt it all to SDL3 but apparently I can postpone it for now.

That’s all for now. There’s a lot to do, maybe some of it will actually be done.

Quicker look at QuickTime

Sunday, February 1st, 2026

Since I’ve done looking at game formats for a while (I’ve updated na_game_tool 0.5.0 release with the fixed extraction of old-style Cryo Interactive archives BTW), I decided to look at my backlog of unsupported (either mis-detected as audio-only or not detected at all) MOV files from discmaster instead. Of course the majority of them are files missing their resource fork (and majority of the rest are poorly-recognised data+resource forks in MacBinary II format; that reminds me I should improve support for it), and majority of the rest are files that I support already (like Duck Truemotion 1 or Eidos Escape codecs). And a good deal of the rest are Flash in MOV (not going to touch it). And yet there are a couple of files worth talking about.

  • 911602.MOV—remarkable for having JPEG frame embedded in QuickDraw stream. It made me finally write a decoder for it (but without JPEG support, maybe one day…);
  • a couple of .flm files turned out to have obfuscated moov atom (with something almost, but not quite, entirely unlike TEA if you care). Not something I’d like to support;
  • La88110mN1Hz2_20-07.mov—it turned out to be raw YUV420 codec;
  • Omni_324.mov—compressed apparently by MicroWavelet on NeXT. Intriguing but I doubt anything else can be found about that codec;
  • Music Chase .tmv—a very weird little-endian MOV format with custom video codec (I think I mentioned it before but I haven’t progressed since);
  • there was one Flip4Mac-produced sample (which name eludes me), but considering that it stores ASF packets inside MOV it’s not something anybody is eager to support;
  • some undecodeable SVQ3 files—apparently they are encrypted;
  • and finally there are some QT Sprite files, which seem to be (often deflate-compressed) frames containing several atoms with commands and occasionally image data as well. Sounds too hairy to support but again, maybe one day…

With AVI situation is somewhat better, there are some poorly formatted and encrypted/obfuscated files as well (plus damaged files from AOL archives that start at random position, so contents may be AVI file with some additional garbage in the beginning or missing few dozens kilobytes of initial data). Beside that I’ll probably implement PDQ2 decoder just for completeness sake. Eventually.