MegaPEG.X Pro 2.0.4 Batch is now available. QT soon. Aside from the bug fixes documented on the support page, new in this version is the inclusion of two different binaries, one optimized for G5 and the other for G4. Currently we're seeing only a small speed increase by using the G5 version, but you have to understand that this first round of G5s represents the first time Apple has gone to someone other than Motorola for PowerPC manufacturing. So all the suggestions in Apple's G5 tuning notes may not come into play until a couple of chip revisions. We'll see. You should try them both on your hardware, G4 or G5 and use the faster one.

The bad news is that to make the product a better Aqua citizen took us out of faster than real-time encoding, regardless as to the frame/size/profile. More research is necessary. The good news is that the speed on the larger frame sizes went up by a whole factor. I reported that 720x480x24p was running at 3:1 on a PowerBook 1.2Ghz, but in the new version it actually is down around 2.1:1. This is on the 'Fast' setting and with no filtering. As well, when I do benchmarks, I try to avoid using a source movie format that is slow to source frames to the encoder, and believe me, there is a very wide range. And on the G5 we saw a big increase. Half-pel motion estimation with exhaustive search on IBBP (which is the equivalent of hardware encoding) is now running at about 5:1; one hour footage, five hours encoding time. That means even the slowest encoding jobs will run easily overnight for a 2hr piece, unless you're encoding sports at 29.97i (with field_prediction)- your mileage then will definitely vary. You'll only see encoding times this slow if you slide the Speed vs. Quality slider to the bottom two notches. Don't use the very bottom notch unless you are encoding interlaced material.

I knew if we simply claimed to rival or exceed the latest 'internet video' compression rates from giants like Microsoft, Real and Macromedia, that sooner or later we would have to show the goods.

So I worked in reverse. A couple of months ago, I took a music video project that I shot on DV and edited in Final Cut and started trying to compress it for use on the www.lobecandy.com web site.

For those of you who don't know, LobeCandy Records is an independent label I started in 1994. We put out quite afew good records, many of which are available as free downloads under a Creative Common license from the web site. Load up your iPod, its AAC and MP3.

As I'm currently upload-bandwidth-challenged, I had an extra interest in making the file as small as possible. So what I did was compress the file with both MPEG-4 and MegaPEG.X, comparing results. As I tuned MegaPEG.X, I realized if I added a couple of new features, I could get us into range of MPEG-4 for this particular piece. So I added those features, and kept working at making the file size smaller. I took the audio track from the video and mastered it in SoundForge on the PC, because I have some special mastering plug-ins on the PC that I really like.

My original goal was to use MPEG-1 Layer 3 (ie. 'MP3') VBR audio, but then I discovered that QuickTime will not play MPEG-1 Layer3 audio embedded as an audio track in an ISO 11172-1 system multiplex. So I abandoned that and went back to using Layer 2, which is so well supported worldwide, well, it hurts.

In any event, I kept improving MegaPEG.X until I got within range of MPEG-4 streaming profile, and lo and behold, one day I came out with a file 2MB smaller than the MPEG-4 file. For reference, my MPEG-4 version of the movie, was about 8MB for about a 4min music video. The MegaPEG.X version ended up at 6MB.

To give the uninitiated reader an idea of how far we've come: in Dec 1998 I wrote a song and put it up on my personal web site in MP3 format. It was about 4min long and I believe I used 128K stereo CBR. The file came out to about 4-5MB. So here we are 6 years later, and I am doing both stereo audio and video at 320x240x24fps and fitting into 6MB.

Like I said, I knew that noone would believe that we had taken a 12-year old ISO standard and made it competitive with all the modern codecs, at least vis a vis the bread and butter publishing of video files on the internet. You know, the talking heads giving presentations, distance learning, product promotions, all these video forms which are not feature films or television shows.

Like I said, I knew noone would believe us, so you can take a look for yourself:
The file is available as a streaming video at www.lobecandy.com/video.php.


I also put it up on the Digigami iDisk along with a screen grab of the actual bitrate compression profile. That's available here:
homepage.mac.com/digigami/

So this particular movie clocks in at about 200 kbps combined audio and video. But I have another compressed file 640x480x25fps that is running at 500kbps. Once I upload it, I will modify this post.

UPDATE: The 640x480x25fps 500kbps stream is available for inspection:
Digigami MegaPEG.X Samples.

If you're using QuickTime Player, the 'noise' you see on the first I-frame is actually a bug in the QuickTime MPEG-1 decoder. The actual bug is in the 'intra inverse quantizer code'. No sweat there, this bug is duplicated in just about every open source MPEG-1 playback code ever written including the berkeley source code and the MSSG code.

You can download the demo of MegaPEG.X Pro and use the built-in bitrate/movie analyzer to check out the quality for yourself. To my eye, it looks a lot better than alot of the stuff I find on the internet. But then, I'm biased.