Last update: 2011/08/21
The unique MPEG way to develop successful standards
It is always so difficult to make a person outside the group understand that MPEG is not in the business of running beauty contests, i.e. of choosing one or a few established solutions among a set of candidates. Indeed MPEG does not typically choose complete solutions, it assembles them from individual technologies. The selection is made using objective criteria, such as numerical results, video or audio quality assessed formally or by collective expert viewing or hearing sessions. By building the solution in the standards committee using objective criteria, MPEG is shielded from the danger of being accused of anticompetitive practices.
MPEG can develop standards in this way because it operates at a different time position than most other standards groups: as a rule MPEG develops a standard before industries have a declared need for it. At that time technologies are in general not fully developed and, therefore, the committee can assemble them on the basis of measurable technical merits. "A priori standardisation" is the qualification that MPEG gives to this notion and is one of the MPEG ground rules.
This positioning avoids certain risks but creates others. As has been shown before for the MPEG-1 case, sometimes companies themselves make gross mistakes in their product development plans: the attraction of a media-related product or service as seen at a board meeting or at the drawing board is often quite different from the attraction felt by a consumer when he has to reach into his wallet to buy the product on the shelf or subscribe to the service offered. Why should MPEG succeed where big companies fail?
One answer to this question is that MPEG does not develop products, but standards, and generic standards at that. The standards may not even be fully suitable to make products. This implies that sometimes adopters pick some of the technology pieces of the standard and very often they need other technology pieces from elsewhere for their products. The second answer is that MPEG has a well structured process to include industry representatives to develop requirements that are then converted into CfPs, both exposed to industry at large.
An additional danger is that, even if the right standard has been spotted, it may be developed too early, and in this case the standard may be superseded by a better technology at the time industry really needs the standard. Conversely, the standard may arrive too late, at a time when companies have made real investments for their own solutions and are not ready to discount the money already spent. The seriousness of this danger can be measured by the state of development of the relevant technologies in the industry.
In the following I will give a general description of the steps followed by MPEG when it develops a new standard. This will hopefully confirm that the process is sound and produces the expected results.
| Step | Description |
| Idea | It is hard to codify the steps leading to the idea of a new standard. Ideas can spring up from discussions and interactions during a meeting, from a specific proposal issued by one or more than one member or a National Body or from the common feeling that more technologies have been developed outside of MPEG, possibly in some laboratories of companies already represented in MPEG, that it may be good to consider for inclusion in one of the existing MPEG standards or in a new one. |
| Involvement | When the decision to develop a standard is made by the group, the affected communities, if not already well represented, are alerted and invited to join in the effort. In the case of MPEG-1 this was a long and difficult process because MPEG was an unknown organisation with no track record. Today things are clearly much easier because there is already a network of liaisons with the principal industry organisations. |
| Requirements | The requirements the standard must satisfy are developed with the participation of all the communities involved. In the case of MPEG-1, the approach was to consider different applications enabled by the standard from which "implications" were derived and from these "technical features". The process, with changed names, is basically still in place today. Typically there are 3 documents: "Use Cases", "Applications" and "Requirements" that are constantly updated. In the requirements development process, a legitimate requirement made by an industry is always included. This is an essential rule if the "multi-industry" qualification of MPEG is to be preserved. |
| Approval | In parallel to this internal process of clarification of the precise purpose of the new standard, there is a need to obtain approval to develop a standard from the ISO hierarchy as a New Project ( NP). This is done by the SC 29 Secretariat (the committee above MPEG) and involves two levels of approval. The first is at the level of the NB members in SC29 and the second at the level of NB members in JTC1 (in ISO a NB may be member of a TC but not of an SC and vice versa). The NP is approved if a simple majority of yes votes is obtained and if at least 5 National Bodies commit to work for it. |
| Timeline | The NP proposal also contains a standard development timeline and MPEG takes pride in sticking to it. This is part of the basic idea that standards are the "goods" that standards committees sell to their customers. As for a company it is clear that the goods have to be of high quality and according to the specification issued by the customers but, first and foremost, they have to be delivered by the agreed date. If a company makes a plan to go to market by a certain date with a certain product that requires a certain standard technology, and makes the necessary investments for it, the company - i.e. the buyer vis-à-vis the standards committee - is not going to be happy if the standards committee - i.e. the supplier vis-à-vis the company - at the due date reports that they are "behind schedule". Therefore "stick to the deadline" is another of the key MPEG precepts. |
| CfP | When the development of requirements has reached sufficient maturity, usually a Call for Proposals (CfP) of technologies capable of satisfying the requirements is issued (a CfP has always been issued when the NP involved audio and visual coding). In recent times, with the existence of audio and video standards by MPEG, it has been found necessary to go through the phase of a Call for Evidence (CfE) before issuing a CfP, to get confirmation of the feeling that new technology exists that is worth standardising. |
| Testing | Proposals must contain a description of the proposed technology with a level of detail from which it must be possible for MPEG to make an implementation. In the case of audio and video coding standards, the CfP also requests the submission of complementary evidence in the form of coded material. The audio or video material is tested according to a procedure described in the CfP. For MPEG-1, MPEG had the great advantage of being able to use the JVC facilities in Kurihama for the video tests and the Swedish Radio facilities in Stockholm for the audio tests. Therefore proponents did not have to pay to have their proposals tested. In the case of MPEG-2 Video the only cost incurred was the preparation of D1 tapes used in the tests. Today it is not uncommon to entrust the tests to a commercial organisation and in this case all proponents are asked to share the cost of the tests. |
| Ranking | Submissions are analysed and ranked along several axes, e.g., subjective quality, complexity, coding delay, robustness to errors, etc. The ranking guides the extraction of the best features from the best proposals to create something new that is based on elements present in the different submissions. This has been called Simulation Model (SM) in MPEG-1 and Test Model (TM) in MPEG-2. |
| CE | The Model evolves from meeting to meeting using the Core Experiment (CE) methodology. A CE is designed so as to enable a collective assessment of the improvement offered by a particular technology providing a certain feature, with all other elements of the CE kept unchanged. At least two companies must take part in the CE in order to have results that qualify for consideration. MPEG is very strict when it accepts technologies and bases its decisions on the "one functionality - one tool" principle, so that no unnecessary duplication of technologies is made. As part of this exercise there is constant attention to assess implementability of the standard. |
| Reference Software | The majority of CEs is carried out using software. In later years (starting with MPEG-4), the originator of the CE of a successfully executed and accepted CE donates the software to ISO. This becomes part of the Reference Software. The software, duly integrated with the rest of the Model, is scrutinised by all members, in the best tradition of Open Source Software (OSS) development. This method of work allows all participants to try different options, and the group to assess the results and select the best solution. It also ensures that there are no "black holes" in the standard that only some participants know and can exploit. The obvious weak point of this method is the time it takes for MPEG to develop a standard. However, the very idea of the MPEG standard development process is based on the assumption that the work is carried out before industries have a need for the standard according to a timeline agreed at the beginning. |
| WD | When the work has reached sufficient maturity, a Working Draft (WD) is produced. This is updated at every meeting. |
| CD | When the WD is considered sufficiently mature and ready for balloting with the NBs, the WD becomes a Committee Draft (CD). NBs consider the CD in their national committees within 3 months from the publication of the CD and cast their ballots with comments. At times several hundred technical comments are received and studied by the group. A comment may be accepted or rejected, but the group must provide a justification for each choice. This appears in a separate document called Disposition of Comments (DoC). |
| DIS | The revised draft standard is published again as Draft International Standard (DIS) and undergoes another ballot with the NBs lasting 5 months. Ballots and comments are again treated as for the preceding ballot. |
| FDIS | The new version of the draft standard is called Final Draft International Standard (FDIS). At this time the document has achieved its final shape. |
| IS | There is another ballot with the National Bodies, very short and without any possibility of changing the technical content of the standard that must remain in the state that it was at FDIS level. After this last ballot the document achieves its final status as International Standard (IS), identified by a 5-digit number. |
| VT | In parallel with the balloting, MPEG carries out the so-called Verification Tests (VT). Once the work is nearing completion, it is important to make sure that the standard does indeed satisfy the requirements ("product specification") originally agreed to by the different affected industries ("customers"). VTs have the purpose of ascertaining how well the standard produced meets the specification in terms of quality. This is obviously also an important promotional tool for the acceptance of the standard in the market place. |
| Corrigendum | Standards are like living organisms. The group or industry users may discover that, in spite of all attentions, an error has crept into the standard. In this case a "corrigendum" is issued. This is balloted only once and becomes immediately effective as soon as the first ballot is successfully resolved. |
| Amendment | It may happen that the group finds that it is possible to enhance the standard with new features. In this case an "amendment" is issued. An amendment is a standard for all practical purposes and therefore it is balloted twice as the other standards with the following names: Proposed Draft Amendment (PDAM), Draft Amendment (DAM) and Final Draft Amendment (FDAM). |
| Withdrawal | It has not happened yet for MPEG, but one day it may happen that a certain standard is considered obsolete. In this case the standard may be withdrawn. |
Not systems but tools is another MPEG precept that has developed in the way MPEG tries to serve multiple industries. By definition industries making end-user products need vertically integrated specifications in order to make products that satisfy their needs. Audio-visual decoding may well be a piece of technology that can be shared with other communities, but if industries need to sell a Video CD player or a digital satellite receiver then these require integrated standards. But if different industries need the same standard, quite likely they will have different end systems in mind. Therefore only the components of a standard, the "tools", as they are called in MPEG, can be specified in an effort designed to serve multiple industries.
The implementation of this principle requires a change of the nature of standards from "system" standards to "component" standards. Industries will assemble the tool specifications from the SDOs and build their own product specification. What constitutes a tool, however, is not always obvious. Single channel and multichannel audio or SDTV/HDTV are components needed in AV systems. Defining a single "tool" that does the job of coding both single channel and multichannel audio or conventional television and HDTV may be impractical because the technology has to be designed and manufactured to do things to an extent that some customers do not need. The "profile/level" philosophy successfully implemented by MPEG provides a solution: within a single tool one may define different "grades", called "levels".
"Specify the minimum" should be a general rule of standardisation. In some environments, however, there is a mixture of technologies that are absolutely indispensable to enable communication and of those components that bring a standard nearer to a product specification. This is, for instance, the case for "industry standards" or when standards are used to enforce the concept of "guaranteed quality" that used to be so dear to broadcasters and telecommunication operators because of their "public service" nature. This is not a good practice and should be abandoned in particular when a standard is to be used by multiple industries. Only the minimum that is necessary for interoperability must be specified in a standard.
Finally "Relocatability of tools" is another MPEG ground rule, again dictated by its multi-industry nature. When a standard is defined by a single industry there is generally agreement on where certain functionalities reside in the system. In a multi-industry environment this may not be the case. Take the case of encryption used in digital television, a tool that has an important value-added function. Depending on your role in the AV distribution chain, you might like to have the encryption function located where it best serves your role in the value chain. If the standard endorses your business model you will adopt the standard, if it does not you will be antagonistic to it. Therefore, not only must the technology be defined in a generic way, but also in such a way that the technology can be located at different points in the system.
Lastly we have the case in which an industry or a vocal member does not want a standard to exist. This is not a logic that MPEG can accept, because of its multi-industry nature. Standards have a positive role to play and serve the needs of interested parties. Those who do not want a standard should have no obligation to use it.
So we are back to the role of regulation vis-à-vis standards.
