Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


ZMBV Tinkering

May 10th, 2008 by Multimedia Mike

Pursuant to that outlandish PAVC idea of mine (that I first started writing about 3 years ago), I began to tinker with the DosBox Video Codec, a.k.a. Zip Motion Blocks Video or ZMBV for short, which was suggested as an alternative the last time I posted about this topic. I have met with some mixed results.

Briefly, the goal of PAVC is to efficiently and losslessly compress frames of video generated by early video game systems, where “early” is defined as anything including and preceding the Super Nintendo Entertainment System. ZMBV is designed to compress, in real time, data from old DOS games running at a number of color modes, with careful consideration given to 8-bit palette data. FFmpeg had an independent ZMBV decoder soon after the codec appeared in DosBox, and also features an independent encoder as well; both the encoder and decoder come courtesy of Kostya.

Item 1: This past week, I found a way to improve the motion estimator in FFmpeg’s ZMBV encoder by changing the assumption it used to compute error between 2 blocks. Michael, being the compulsive mathematical gambler that he is, said, “I’ll see your rudimentary error minimizer and I’ll raise you a 0th-order entropy approximater.” No, I don’t understand what that means either. But the net result is that all 8-bit files that FFmpeg converts to ZMBV are notably more compact. Score 1.

Item 2: Read the rest of this entry »

Posted in Open Source Multimedia, PAVC | 2 Comments »

Revenge Of PAVC

November 18th, 2007 by Multimedia Mike

Remember my old PAVC idea? I have been thinking about it again. As a refresher, this idea concerns efficiently and losslessly compressing RGB video frames output from an emulator for early video game systems such as the Nintendo Entertainment System (NES) and the Super NES. This time, I have been considering backing off my original generalized approach and going with a PPU-specific approach. (PPU stands for picture processing unit, which is what they used to call the video hardware in these old video games systems.) Naturally, I would want to start this experiment (again) with my favorite — nay — the greatest video game console of all time, the NES. Time for more obligatory, if superfluous, NES screenshots.

Little Samson (NES) game map
Little Samson
, all-around awesome game

Here’s the pitch: Modify an emulator (I’m working with FCE-Ultra) to dump PPU data to a file. Step 2 is to take that data and run it through a compression tool. What kind of data would I care about for step 1? On the first frame, dump out all of the interesting areas of the PPU memory space. This may sound huge, but it is only about 9-12 kilobytes, depending on the cartridge hardware. Also, dump the initial states of a few key PPU registers that are mapped into the CPU’s memory space. As the game runs, watch all of these memory and register values and log changes. This really isn’t as difficult as it sounds since FCEU already cares deeply when one of these values changes. When something changes, mark it as “dirty” and dump that value during the next scanline update.

With that data captured, the next challenge is to compress it. I am open to suggestions on how best to encode this change data. I would hope that we could come up with something a little better than shoving a frame of change data through zlib.

Decompression and playback would entail unraveling whatever was performed in step 2 above. Then, the decoder simulates the NES PPU by drawing scanline by scanline, and applying state change data between scanlines.

What are the benefits to this approach? Ideally, I am aiming not only for lossless compression, but for better compression than what is ordinarily achieved with the large files distributed via BitTorrent and coordinated at When I first started investigating this idea over 2 years ago, MPEG-4 variants were still popular for compressing the videos. These days, H.264 seems to have taken over, which performs much better, even on this type of data (allegedly, H.264’s 4×4 transform allows for lower artifacts on sharp edge data such as material from old video game consoles).

Sword Master (NES)
Sword Master
, mediocre game with great graphics

There are also some benefits from the perspective of NES purists. The most flexible NES emulators allow the user to switch palettes in order to get one that is “just right”. A decoder for this type of data could offer the same benefits.

Of course, an encoder is not much use without an analogous decoder that end users can easily install and use. I think this is less of an issue due to the possibility of creating a decoder in Flash or Java.

Posted in Outlandish Brainstorms, PAVC | 7 Comments »

PAVC: Bisqwit Forum Discussion

August 16th, 2005 by Multimedia Mike

A few weeks ago, I posted a new thread over on Bisqwit’s Nesvideos forums about my experimental codec research: Custom Video Codec For Console Movies. There has been some interesting discussion regarding PAVC-related compression concepts and it is worth reading.

It has been a little while since I have posted a gratuitous console game screenshot. For a change, instead of posting a screenshot of a game of which I have fond memories, I am posting a screenshot of one of the most dreadful games ever published on the NES:

Bad Game: Heroes of the Lance
Heroes of the Lance

Thanks as always to MobyGames and their vast screenshot archive.

Posted in Open Source Multimedia, PAVC | 1 Comment »

Getting Serious About PAVC

August 5th, 2005 by Multimedia Mike

I realized recently that I have completed my initial goals laid out in this post. And since this is a post about PAVC, let’s start out with some pretty console screenshots:

Metal Storm
Metalstorm, NES,
one of the most graphically complex games on the NES console

Read the rest of this entry »

Posted in Open Source Multimedia, PAVC | Comments Off on Getting Serious About PAVC

« Previous Entries