Category Archives: Open Source Multimedia

News regarding open source multimedia projects.

Eee PC Multimedia

Call it a $350 impulse buy, but I just read about this thing called the Asus Eee PC last week and decided to order one. It arrived today and I am composing this entry on the machine. People who know me know that I am not a gadget freak, nor am I at all enamored with notebook computers; in fact, I have traditionally despised laptop computing (and anytime I have been to a Linux conference, I am typically the only laptop-less geek in attendance). Now, here I am with a subnotebook-class computer with a 630 MHz CPU, 4 GB of flash storage, and a 7-inch, 800×480 display.

The Eee PC runs a customized version of Linux with a KDE desktop out of the box. I have been reading a lot about how to get this or that version of Linux (or even WinXP or Vista) installed. I figured I will just go with what they have for now until I encounter some severe limitation. I am trusting that their default installation probably knows a few tricks about working with the hardware set that other OSes are not yet hip to. At the very least, I didn’t have to fight with anything; everything just works out of the box, including the wireless capability. This is nice since this is the first time that I have ever personally set up anything wireless. I’m a bit behind; remember that I didn’t get broadband internet until mid-2004.

So let’s talk multimedia. At the very least, the unit comes with Adobe Flash Player, albeit the old version of #9. I guess I can’t expect the very latest version 9, which was released last week, about the same time that I placed the order for this unit.

Via network is pretty much the only way to get anything on or off this unit. I was able to mount my shared media folders effortlessly. Clicking on a MP3 file associates to Music Manager, which is apparently Amarok but with friendlier name. PCM WAV files are also handled, though the first ones I try sound really bad — I’ll need to look into what’s going wrong with that. OGG and WMA are similarly handled.

Time to throw my favorite movie trailers at the system. A QuickTime file is handled by Media Player — a friendlier name for SMPlayer — and, uh oh: IMA ADPCM is handled but SVQ1 is not, nor is SVQ3. Cinepak is deemed “safe”, however. All MPEG codecs and Microsoft codecs seem to work just fine. WMV8 works fine, so it could be that it has a really recent build of FFmpeg that includes X8Intra frames, or Linspire-style codecs, or Microsoft binaries through Win32 support. My money is on the Linspire-type option since the decoding is quite slow. DivX/ISO MPEG-4 video seems to work out of the box, H.264 video does not.

For miscellany, DosBox Video and FILM/CPK files work out of the box with SMPlayer.

I look forward to working with this little machine further. First off is to decide how to be just a tad more flexible with it. The default installation is designed to aggressively resemble the silver-themed Windows XP UI in every way imaginable. That doesn’t bother me so much as the fact that I don’t know how to install any other software (the Add/Remove Software option is incredibly limited) or even find a terminal yet. Hopefully, this will all become clear with the help of the extensive manual so that I will not have to switch to another OS.

Update: I can run MPlayer from the command line and confirm that the player is using the FFmpeg decoder for handling WMV8. So Asus is quite up to date.

MDEC Comeback

I just wanted to draw attention to a recent effort by one Michael Sabin who has been building a Java application called jPSXdec to play back videos ripped from the Sony PlayStation 1.


Sony PlayStation

To review, the original PlayStation had a bit of dedicated hardware called the motion decoder (MDEC) which decoded specially formatted blocks of what were essentially motion JPEG data. Assorted games also compressed the blocks using Huffman codes which were decoded by software. While the MDEC hardware was rigid in the data it would accept, PS programmers could deploy whatever Huffman tables they chose. I always thought it would be an interesting project (and a natural extension of my usual efforts) to catalog the various tables needed to play movies from different games, as well as different strategies that games have used to store the data on the disc.

Michael S. has been doing just that. There is a blog to document jPSXdec’s progress. Near and dear to my heart, however, is the fact that he is building a remarkable document (seen in the project’s download list) that explains precisely how to decode this data, from the perspective of a non-multimedia geek, no less.

YouTube’s Lucky Number

The number is 240. In learning how YouTube works its magic so that MobyGames may one day take user’s video submissions, Trixter has been doing his own poking at the video giant to determine what parameters the site uses to transcode user videos. What he learned: 240 lines, 240 kbps, 240 frames in a GOP. His best guess for why things are the way the are: …”it sure seems like the YouTube guys were taking blind stabs at encoding parameters (ie. ‘Hey, let’s set everything to 240 and see what happens!’).”

Revenge Of PAVC

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 tasvideos.org. 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.