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 from a set of candidates. Indeed MPEG does not typically choose complete solutions, it assembles them from individual technologies, possibly at different levels of granularity. 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 and possibly improve them on the basis of measurable technical merits. “A priori standardisation” – the qualification MPEG gives to this notion – 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. An MPEG standard could very well not be fully suitable for making 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 to make 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 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 has a track record of very successful standard, the imprint of success is not necessarily inherited from the MPEG name. Indeed there are MPEG standards that have received little or no attention. This is 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 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 main industry organisations. |
| Requirements |
The requirements the standard must satisfy are 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, is basically still in place today. Typically there are 4 documents: “Context and Objectives”, “Use Cases”, “Applications” and “Requirements” that are constantly updated. In the requirements development process, a legitimate requirement proposed by an industry is always included, possibly after a long debate to understand if this is really a new or just an extension of an already identified requirement. 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 an approval to start a New Project (NP) leading to a standard from the ISO hierarchy. 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 on 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 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” is another of the key MPEG precepts. |
| CfP |
When the requirements are sufficiently mature, usually MPEG issues a Call for Proposals (CfP) of technologies capable of satisfying the requirements (a CfP has always been issued when the NP involved audio and visual coding). In recent times, as there are existing 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 group’s 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 selected by the group for the CfP (or the CfE) is provided to those responding to the call and the encoded material is 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. 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 |
As a rule CEs are 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 for that standard. 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 and 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 (technical) 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 it had 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 itself or an industry user 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, as the other standards, it is balloted twice 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. However, as MPEG defines media formats, I expect that no MPEG standards will 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 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 are called in MPEG, can be specified in an effort designed to serve multiple industries.
The implementation of this principle has 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 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 – 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” 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 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 cannot accept, because of its multi-industry nature. Standardisation is a service offered to those who need it. Those who do not want a standard should have no obligation to participate in its development nor to use it. And, also, they have no right to tell other people that a certain standard should not exist.
