The videos decode, picture for picture
2026-10-24, the clean-room video session.
POD's videos are Intel Indeo 4.1. Earlier today a first decoder was withdrawn, because it had been written with help from another project's code. This session started again from Intel's own codec, IR41_32.DLL, which is on Gold's disc. Every rule was read in Intel's code, or measured by running Intel's code in the emulator, and written down with its address in Videos.
How it was done
Intel's codec runs in GameFrame's emulator: its DriverProc is given each chunk of an AVI file, as Video for Windows would give it. Its output is the ground truth. The emulator also lets the session look inside Intel's decoder while it works: the list of blocks it builds for each tile, and the 16-bit samples of each band before they become pixels. When POD's decoder went wrong, those showed exactly where.
Most of Intel's decoder is careful C, and its structure came straight from the decompiler: the picture header, the bands, the tiles, the macroblocks. The inner parts are hand-written assembly. Intel's Pentium code decodes two blocks at once, the left one in the low half of each 32-bit word and the right one in the high half, and its inverse transforms add and shift both halves together. Rather than guess what that arithmetic means, the session translated each transform from Intel's code word for word. Then it ran Intel's own routines and the translations on 2,400 buffers, random ones included, and every result matched.
What went wrong, and why
The first picture tried, the logo, had its luma right at once and its chroma wrong. Intel's coefficient buffers showed the colour coefficients landing a row off. Intel keeps its 4 × 4 scan orders four positions a row on disk, and widens them to eight at start-up (FUN_10001400); the session had read the tables from memory once, after that step, and from the file the second time. With the start-up step added, the logo matched.
The credits, four bands of luma, then differed by a few levels in some places. One of the four bands has no transform at all. When one of its blocks is not coded, Intel fills only its first sample with the predicted DC and leaves the rest at zero (0x4000), unlike the transformed bands.
The predicted pictures of FINPOD2.AVI went wrong from their second row of macroblocks. Intel's block lists showed that an empty macroblock in a predicted picture is not intra, as in an intra picture: it is a forward copy with no motion. A table lookup the session had skipped maps one to the other. With that fixed, all 156 pictures matched, the held-back ones and the bidirectional ones too.
The result
| File | Pictures | Equal to Intel's codec |
|---|---|---|
LOGO.AVI | 1 | 1 |
CREDITS.AVI | 131 | 131 |
FINPOD.AVI | 1,413 | 1,413 |
FINPOD2.AVI | 156 | 156 |
INTROPOD.AVI | 5,981 | 5,981 |
INTROCD.AVI | 5,981 | 5,981 |
All of them byte for byte (measured). FFmpeg's ffmpeg program, run as a black box for comparison, disagrees with Intel's codec on every four-band picture and on many predicted ones. Intel's codec is the reference.
The decoder is in crates/pod-video (pod_video::indeo), and in GameFrame as gameframe-indeo. Intel's tables are not copied into either: they are read from the player's own IR41_32.DLL. GameFrame's new ir41_32.dll is a Video for Windows codec on the same decoder. Under Wine, Windows' own AVIStreamGetFrame played FINPOD2.AVI through it, and its pictures were Intel's exactly.
In the original game
In the emulated PC, with the codec installed as Intel's setup did, Gold's WINPOD.EXE plays its intro through it: no "Indeo not installed" picture in 25 captures. The two Direct3D builds, which crashed in their AVI player without a codec, play the intro and reach the menus.
What is next
- The videos in Un-POD, with their sound.
- Intel's MMX path recomposes four-band pictures slightly differently from its Pentium path; a modern PC running Intel's codec would take the MMX one. The decoder could offer both.