The MPEG Way of Standards Making

It used to be difficult to make a person outside the group understand that MPEG was not in the business of running beauty contests, i.e. of choosing one or a few established solutions from a set of candidates. Indeed MPEG did not typically choose complete solutions, but it used to assemble them from individual technologies, possibly at different levels of granularity. The selection was 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 was shielded from the danger of being accused of anti-competitive practices. 

MPEG could develop standards in this way because it operated at a different time position than most other standards groups: as a rule MPEG developed a standard before industries had a declared need for it. At that time, technologies are in general not fully developed and, therefore, the committee can assemble and possibly improve them on the basis of measurable technical merits. “A priori standardisation” – the qualification MPEG used to give to this notion – was one of the MPEG ground rules. 

This positioning avoided certain risks but created 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 have succeeded where big companies failed? 

One answer to this question is that MPEG did not develop products, but standards, and generic standards at that. An MPEG standard could very well not be fully suitable for making products. This implied that sometimes adopters pick some of the technology pieces of the standard and very often they need other technology pieces from elsewhere to make their products. The second answer is that MPEG had a well structured process to to develop requirements by including industry representatives for later conversion into Call for Proposals, 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 their investments. The seriousness of this danger can be measured by the state of development of the relevant technologies in the industry.

In general we can say that while MPEG had a track record of very successful standard, the imprint of success was not necessarily inherited from the MPEG name. Indeed there were MPEG standards that did receive little or no attention. This was an unavoidable consequence of the MPEG time positioning. 

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 that led to the idea of a new standard. Ideas could 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 had been developed outside of MPEG, possibly in some laboratories of companies already represented in MPEG, that it might 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 was made by the group, the affected communities, if not already well represented, were 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. Later, things got much easier because there was already a network of liaisons with the main industry organisations.
Requirements	The requirements the standard was required to satisfy were developed with the participation of all 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, remained basically in place. Typically, there were 4 documents: “Context and Objectives”, “Use Cases”, “Applications” and “Requirements” that were constantly updated as discussions continued. In the requirements development process, a legitimate requirement proposed by an industry was always included, possibly after a long debate to understand if this was really a new or just an extension of an already identified requirement. This was an essential rule to preserve the “multi-industry” qualification of MPEG.
Approval	In parallel to this internal process of clarification of the precise purpose of the new standard, there was a need to obtain an approval to start  a New Project (NP) leading to a standard from the ISO hierarchy. This was done by the SC 29 Secretariat (the committee above MPEG) and involved two levels of approval. The first 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 Technical Committee but not of an SC and vice versa). The NP was approved if there was a simple majority of yes votes and if at least 5 National Bodies committed to work on it.
Timeline	The NP proposal also contained a standard development timeline and MPEG took pride in sticking to it. This was part of the basic idea that standards are the “goods” that the standards committee “sells” to its customers. As for a company it is clear that the goods have to be of high quality and conform 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” was another of the key MPEG precepts.
CfP	When the requirements were sufficiently mature, usually MPEG issued a Call for Proposals (CfP) of technologies satisfying the requirements (a CfP was always issued when the NP involved audio and visual coding). Later, as there were existing MPEG   standards for audio and video, it was found necessary to go through the phase of a Call for Evidence (CfE) before issuing a CfP, to get confirmation of the group’s feeling that new technology exists that was worth standardising.
Testing	Proposals had to contain a description of the proposed technology with a level of detail enabling MPEG to make an implementation. In the case of audio and video coding standards, the CfP also requested the submission of complementary evidence in the form of coded material. The audio or video material selected by the group for the CfP (or the CfE) was provided to those responding to the call and the encoded material was tested according to the 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. Later, it was 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 were analysed and ranked along several axes, e.g., subjective quality, complexity, coding delay, robustness to errors, etc. The ranking guided the extraction of the best features from the best proposals to create something new that was based on elements present in the different submissions. This was called Simulation Model (SM) in MPEG-1 and Test Model (TM) in MPEG-2.
CE	Then the Model evolved from meeting to meeting using the Core Experiment (CE) methodology. A CE was 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 had to be part in the CE in order to have results that qualified for consideration. MPEG was very strict when it accepted technologies and based its decisions on the “one functionality – one tool” principle, so that no unnecessary duplication of technologies was made. As part of this exercise there was constant attention to assess implementability of the standard.
Reference Software	As a rule CEs were carried out using software. In later years (starting with MPEG-4), the originator of the CE of a successfully executed and accepted CE donated the software to ISO which became part of the Reference Software for that standard. The software, duly integrated with the rest of the Model, was scrutinised by all members, in the best tradition of Open Source Software (OSS) development. This method of work allowed all participants to try different options, and the group to assess the results and select the best solution. It also ensured that there were no “black holes” in the standard that only some participants know and could exploit. The obvious weak point of this method was the time it took for MPEG to develop a standard. However, the very idea of the MPEG standard development process was based on the assumption that the work was carried out before industries had a need for the standard according to a timeline agreed at the beginning.
WD	When the work reached sufficient maturity, a Working Draft (WD) was produced and updated at every meeting.
CD	When the WD was considered sufficiently mature and ready for balloting with the NBs, the WD became a Committee Draft (CD). NBs considered the CD in their national committees within 3 months from the publication of the CD and casted their ballots with comments. At times several hundred technical comments were received and studied by the group. A comment might be accepted or rejected, but the group had to provide a justification for each choice. This appeared in a separate document called Disposition of Comments (DoC).
DIS	The revised draft standard was published again as Draft International Standard (DIS) and underwent another ballot with the NBs lasting 5 months. Ballots and comments were again treated as for the preceding ballot.
FDIS	The new version of the draft standard was called Final Draft International Standard (FDIS). At this time the document achieved its final (technical) shape.
IS	There was another ballot with the National Bodies, very short and without any possibility of changing the technical content of the standard that had to remain in the state it had at FDIS level. After this last ballot the document achieved its final status as International Standard (IS), identified by a 5-digit number.
VT	In parallel with the balloting, MPEG carried out the so-called Verification Tests (VT). Once the work neared completion, it made sure that the standard did indeed satisfy the requirements (“product specification”) originally agreed to by the different affected industries (“customers”). VTs had the purpose of ascertaining how well the standard produced met the specification in terms of quality. This was obviously also an important promotional tool for the acceptance of the standard in the market place.
Corrigendum	Standards are like living organisms. The group itself or an industry user could discover that, in spite of all attentions, an error had crept into the standard. In this case a “corrigendum” was issued. This was balloted only once and became immediately effective as soon as the first ballot was successfully resolved.
Amendment	It could happen that the group found that it was possible to enhance the standard with new features. In this case an “amendment” was issued. An amendment was a standard for all practical purposes and, as the other standards, it was balloted twice  with the following names: Proposed Draft Amendment (PDAM), Draft Amendment (DAM) and Final Draft Amendment (FDAM).
Withdrawal	It never happened for MPEG, but one day it could have happened that a certain standard was considered obsolete. In this case the standard might have to be withdrawn. As MPEG defienes media formats, I expect that no MPEG standard will ever be withdrawn.

Not systems but tools is another MPEG precept that was developed in the way MPEG tried to serve multiple industries. By definition, industries making end-user products need vertically integrated specifications so that they can make products satisfying 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 DVD player or a digital satellite or Over The Top (OTT) receiver then they 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 were called in MPEG, could be specified in an effort designed to serve multiple industries. 

The implementation of this principle required 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 provided a solution: within a single tool, different “grades”, called “levels” were defined. 

“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 – as far as standards are concerned – 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” was 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 is not always 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 antagonise 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 a logic that MPEG did not accept, because of its multi-industry nature. Standardisation is a service offered to those who need it, not a tool to prevent other people to have the standard they need. Those who do not want a particular standard should have no obligation to participate in its development much less to use it. And, also, they have no right to tell other people that a certain standard should not exist.