Last update: 2011/08/21
In spite of being a standards group operating in an industrial environment, MPEG has developed software using principles similar to Open Source Software.
It has already been said that MPEG had to deal with the software aspects of its work from very early on. The first MPEG-1 Video Simulation Model, fully assembled at the Tampa meeting in March 1990, was still a traditional textual description but, at the first Santa Clara, CA meeting in August 1990, pseudo C-code complement the text of the standard. For people accustomed to write computer programs this means of expression was more natural and more effective than words to describe the operations performed by the codec.
In MPEG-1 and MPEG-2 times active participants individually developed and maintained their own simulation software. Some time later, as has been reported, the decision was made to develop reference software, i.e. a full software implementation of the MPEG-1 standard.
Seen with the eyes of a software developer, the process of standard development in MPEG-1 and MPEG-2 times was rather awkward, because the temporal sequence of steps was:
With MPEG-4 a new world came to the fore. Software was no longer just a tool to develop the standard; it was in the process of becoming the tool to make many (even though not all) products based on the standard. A reversal of priorities was required because the standard in textual form was still needed - a traditional method of expressing standards cannot be changed overnight - but for many users the standard expressed in a programming language was meant to be the real reference. This applied not just to those making software implementations, but also those making more traditional hardware-based products and VLSI designs. Therefore it was decided that the software version of the standard should have the same normative status as the textual part.
Quite independently from the formalisation of the OSS rules that were already taking place in the general IT world, MPEG made the decision to develop the reference software collaboratively. One of the reasons was that better software would be obtained if participants shared the code. Another reason was that, by having two different forms of expression, a standard of improved quality would be obtained, because the removal of an ambiguity from one form of expression would help clarify possible ambiguities in the other. Also, the scope of MPEG-4 was so large that probably no company could afford to develop the complete software implementation of the standard. Finally, a software implementation made available to the industry would result in an accelerated adoption of the standard.
I do not claim that MPEG has followed the rules that the OSI has set to call a piece of software OSS. I am just saying that even within a peculiar environment like an SDO, driven by very clear industrial interests, collaborative software development naturally ends up obeying similar rules. These are the first rules set by MPEG
For each portion of the standard, a manager of core experiments was also appointed. This manager integrated the code of the accepted tools in the existing code base. The following companies and organisations appointed a representative for the corresponding portions of the MPEG-4 standard.
| Company | Portion of MPEG-4 |
| Apple | MP4 File Format |
| ETRI | Text-to-Speech Interface |
| Fraunhofer | Natural audio |
| Microsoft | Video code in C++ |
| MIT | Structured Audio |
| MoMuSys | Video code in C |
| Optibase | Core |
| Sun | MPEG-J |
In the table, "Core" is the portion of code on which all media decoders and other components plug in.
Unlike traditional OSS projects, only MPEG members canparticipate in the project, a consequence of ISO rules related to standards development. Discussions, however, are usually done on email reflectors that are open to non-MPEG members.
The so-called "copyright disclaimer" that is found on all MPEG-4 software modules establishes the following points:
Of late some objections have been raised to the clause that MPEG-4 reference software should be licenseable only for "conforming products". The first objection, the same that is made to OSS in general, is that access to the reference software may contaminate employees of a software company. The second objection is that the reference software of a standard should not have any restriction, e.g. it should be in the public domain. The response to this second objection is that an SDO is in the business of promoting its own standards, not to promote the public domain software philosophy in general, much less competing standards. Besides, having that clause prevents forking, as is also a concern for software companies.
The joint project with ITU-T to develop the Advanced Video Coding (AVC) standard has prompted some changes to the reference software policy. The first is the possibility for the original developer of the code to simply donate the code without possibly identifying himself. The second is the possibility to reuse the code in other ISO/IEC and ITU standards. The latter covers the obvious case where, say, the DCT transform code can be reused in other standards that make use of the DCT.
The MPEG OSS approach has been extended to two other cases. One case was motivated by the fact that, while the reference software is intended to be "reference" (normative or informative as the case may be), it is not necessarily intended to be efficient. Therefore since December 1999 MPEG has been working on MPEG-4 part 7 that contains optimised code, e.g. optimised motion vector search, a computationally very expensive part of an encoder implementation, where savings of more than one order of magnitude can easily be achieved. Any implementer can take this code and use it under the same conditions as the rest of the reference software, with the added condition that optimised code should not require the use of patents.
More recently MPEG has started using the Berkeley Software Distribution (BSD), originally used to distribute a Unix-like operating system.
