MPEG 4 is perhaps one of the most misunderstood technologies on the internet today. Everywhere you go people that seem to know what they are talking about contradict other seemingly knowledgeable people on nearly every aspect of MPEG 4. I can't claim to be a member of the MPEG 4 committee, nor can I claim to be a developer of any MPEG 4 based technology. I am simply an avid user that has followed it for several years. I grow weary of seeing people posting their misconceptions of MPEG 4 as fact on every board on the internet, but I really can't blame them, because there is not really any place that you can just go educate yourself on MPEG 4. Throw the Mac into it and it gets even more confusing. This article is an attempt to set the record straight. It will undoubtedly fail on at least a few points, but if nothing else it will bring readers significantly closer to understanding MPEG 4 on the Macintosh.

MPEG 4 came to matter to a large number of users because of a misconception that they were using it to share movies and tv shows. The flavor of "MPEG 4" that users believed they were using was called "DivX ;)" The reason that users believed DivX ;) to be MPEG 4 stems from the foundation that DivX ;) was based on. DivX ;) is a hack of a CODEC called MS-MPEG 4v3. MPEG 4 has undergone 3 revisions(v1, v2 and v3), and interestingly enough Microsoft has made 3 revisions to it's implementation of MPEG 4. This sure makes it sound like DivX ;) is MPEG 4 based, doesn't it? The problem is that the MPEG (Moving Picture Experts Group) puts out a document that describes how an MPEG 4 bitstream should be decoded. If you write code that does the things that are described in this document, you will be able to decode any MPEG 4 compliant file. If you were to create such a decoder, you would find that it does not decode any MS-MPEG4 files. Thus MS-MPEG4, while based on MPEG 4, is not MPEG 4. (Imagine that: Microsoft helps develop a standard and when they implement it they bastardize it to a point of non-compliance!)

Microsoft released MS-MPEG4 v3 in several of their releases of Windows Media Player (WiMP) for Windows. A guy going by the handle Gej (Jérôme Rota) hacked it to use an avi container instead of an asf container. This allowed users to use non-Microsoft encoding tools to produce very good quality video at surprisingly low bitrates. This also allowed them to use higher quality audio codecs, such as mp3 or ac3, rather than just wma which is the only audio CODEC Microsoft's tools support. DivX ;) is born. Windows users were suddenly able to encode and playback video that is "near-DVD quality" and is small enough that an entire movie can fit on a single CD. Many have referred to it as "the MP3 of video compression." Internet video file sharing reached a new high, also due to the advent of software that made it possible to overcome the copy protection on a DVD disc, and the increasing commonality of broadband internet connections.

Mac users were out of luck when it came to playing back DivX content for quite some time. Eventually a fellow going by the name of Capt. Stux Jedi (I haven't stumbled into his real name yet...) figured out that WiMP 6.x for Macintosh had an implementation (albeit a rather poor one) of the MS-MPEG4 decoder, and he proceeded to write an application that used that decoder in much the same way that Gej's "CODEC" relied on the Windows version of WiMP, except that Stux made his own player which he eventually piped to a quicktime output. Mac users could suddenly watch DivX content and transcode it to other formats. This solution worked, but it was very slow and did not offer the image quality that DivX ;) on the PC offered. The other major problem that came up with this decoder (which still hasn't been fully resolved) is that the QuickTime avi handler cannot correctly parse the header of an avi movie that contains VBR MP3 audio. This is not a bug, and one should not be upset with Apple for this. Apple is simply adhering to standards- the avi standard does not allow for VBR audio. DivX movies have to be "doctored" before they can be played in QuickTime, which unfortunately takes time and additional disk space.

Linux users were able to use DivX almost immediately after it first came out, but only if they were using x86 hardware as they were actually just running the WiMP .dll's inside of another media player. This was great, but what many Linux users love about Linux is its platform independence. Eventually someone (a fellow by the name of Gerard Lantau) decided a more platform independant solution needed to be developed. All hail ffmpeg. Totally coded from the ground up by looking at the bitstream and figuring out how to decode it properly, there now was a platform independant open-source DivX encoding and decoding engine (it also gained over time the ability to encode and decode a pretty tremendous array of other formats and more formats continue to be added). Linux programs such as MPlayer utilized this engine for DivX playback and now encoding.

This was a *REALLY* good thing for Mac users who had adopted Mac OS X. Lord Crosis (the author of this article) was informed about ffmpeg and started making noise about it in every Mac forum he could find, and trumpeted the possibilities of this CODEC with Mac OS X. Unfortunately his limited UNIX knowledge didn't allow him (I love speaking self-referentially in the third person) to compile ffmpeg for OS X, but someone by the name of Mark from OAAI saw one of his posts and rapidly had ffmpeg up and running from the command line. Big step forward, we could now transcode to and from DivX! Soon after, Michael Stuurman of jamby managed to encapsulate the ffmpeg decoder in a QuickTime component and suddenly we had a QuickTime compatable DivX player running natively under Mac OS X with better than ever performance on the Mac. He said he would have the encoder portion of it working soon after, but we have heard nary a thing of his project since. This decoder is only available for Mac OS X because of its *nix heritage, and unfortunately still does not solve QuickTime's avi issues, but offered us the first OS X native DivX doctoring solution, avi2mov.

When Stux hacked together a Mac DivX player he saw a lot of things that could be done to produce a true MPEG-4v3 CODEC with the benefits of improving image quality and reducing file sizes without drastically increasing system requirements. Better still because it didn't rely on anyone else's code, and since it used Apple's mov format as it's file container, it would be truly cross platform. A few months later an early developmental version of 3ivx was released for Windows, Mac OS 9 (and shortly after X), Linux, and even BeOS and Amiga! 3ivx is in many ways one of the most advanced video CODECs out there. Initially it's largest downside was that it was unable to playback DivX content and thus content needed to be re-encoded to be used with it. It hasn't gained a lot of momentum as the only versions released thus far have been somewhat slow, and have not fully exploited it's potential image quality. But Stux and his team are hard at work on the next version, d4 which promises to remedy all of these issues. They have actually released a preview of the d4 decoder for Mac only, and one of the best things about it is that like the ffmpeg team, the 3ivx team reverse engineered the DivX bitstream so that 3ivx could decode DivX movies. Released at the same time was DivX Doctor II, which is a much more thorough and functional doctoring solution than avi2mov. To this day I see this as the best Mac DivX playback solution out there.

Gej went on to put together a team that produced an Open Source MPEG 4 CODEC called OpenDivX. Just as has occured in this article, somewhere along the way the ;) was dropped from the name DivX ;). This CODEC actually had nothing to do with DivX itself but because so much buzz had been generated about "DivX" he continued to work under the name. It turned out that this was merely a way of building hype and getting feedback and assistance in developing his secret project. They say the best way to keep a secret is to put it right out in the open where everyone can see it, and apparently he took this to heart. After acquiring the rights to the trademark for "DivX" and domain name DivX.com from Circuit City, DivX.com opened and they introduced DivX 4.0. DivX 4.0 is loosely based on OpenDivX, and it is certainly in the same playing field as 3ivx. Ironically DivX Networks had to do the same thing the 3ivx and ffmpeg teams had to do: Reverse engineer the bitstream for DivX 3.11 movies so as to enable playback of already encoded DivX movies without reliance on Microsoft code. Several months later DivX Networks released a Mac version in the form of a late alpha release of the decoder only, with an encoder forthcoming. The developer of this CODEC is a long time Mac user and programmer who goes by Adrian B. Performance with this DivX decoder is at least as good as that of the ffmpeg decoder, and the image quality is notably better. Unfortunately this still didn't offer a solution to QuickTime's avi issues. More recently DivX Networks released DivX 5.0, which offers a slew of encoding and decoding enhancements, both in terms of performance and image quality. This time along with the release of the Windows CODEC, Mac users got an alpha release at the same time. Again the Mac release is only a decoder with an encoder promised, but it improves performance, adds compatibility with DivX 5 movies, and most importantly represents the first step towards resolving QuickTime's avi handling issues. With this release you can use a "validator" program that changes the creator code of a DivX movie. When you open it in QuickTime, rather than using QuickTime's built in avi handler, the DivX CODEC parses the avi header. It works (barely) and Adrian B. promises it will become much better in future releases.

There's also Sorenson MPEG-4 which Sorenson seems to have been silent about for quite some time. At one point a preview was released, and though it looked promising, it doesn't hold up to current mpeg 4 projects. I have heard it was rolled into their Flash based video products.

A couple of programs have been released that do overcome QuickTime's avi issues by simply taking QuickTime out of the picture. VideoLAN Client (VLC) is a cross platform open source media player which plays darn near every non-quicktime format out there. Most recently they have added ffmpeg to it to allow it to play back DivX movies. It does this without any doctoring, and if you have a fast Mac it does a pretty decent job. The above mentioned MPlayer has been ported to Mac OS X and will also play back DivX using ffmpeg without doctoring, albeit a little more slowly than VLC. If you ask me though, I will tell you the best solution for playing DivX on the Mac is still 3ivx D4. If you want to see proof of this in action, download the 1024x468 DivX encoded Warcraft III trailer which is the highest res DivX movie I am aware of, and play it on various hardware with various decoders. 3ivx will handle it on just about any G4 flawlessly. DivX does next best and plays it acceptably, though still not perfectly and with lower image quality, on a dual 1 GHz G4. All other decoders absolutely choke on it regardless of hardware.

Apple has also now released their official MPEG 4 CODEC. It doesn't seem to me to be as advanced as some of the alternatives, but it's nice to have a built in MPEG 4 CODEC included with QuickTime. I wouldn't mind seeing Apple bundle 3ivx instead though. :)

I hope this article has been worth the read, I intend to revise and improve it as I get corrections/new information. This may eventually evolve into an FAQ as I plan to maintain it as MPEG 4 evolves. If there are any points in which I may be mistaken, I would be delighted if someone would point out my errors to increase the accuracy of the information provided here. If anyone feels that I have missed anything useful here, drop me a line and I will consider adding it.