|
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 (I cannot
guarantee, though, that some MPEG members would not be interested in running
real beauty contests). MPEG does not 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: 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 is given to this idea 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 or subscribe to the service. 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 formed. This implies that adopters
can pick some of the technology pieces of the standard and very often
they will 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 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 when MPEG develops a 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 without a proven 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
is an "Applications" document and a "Requirements"
document that are constantly updated. In the requirements development
process, a legitimate requirement made by an industry will be 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 as an 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 a 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 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
the goods of course have to be of high quality, they have to be according
to the specification issued by the customers but, foremost, they have
to be delivered by the agreed date. If a company makes a plan to go
to the market by a certain date with a certain product that requires
a certain standard technology, and makes the necessary investments
for it, the company - the buyer vis-à-vis the standards committee
- is not going to be happy if the standards committee - 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 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, 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 standardisation. |
| 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 proponents
are asked to share the cost of the tests. |
| Ranking |
Submissions are analysed and the
results enable the ranking of proposals 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 SM in MPEG-1 and TM in MPEG-2. |
| CE |
The Model evolves from meeting to
meeting using the CE methodology. A CE is designed so as to
enable an assessment - by the group - 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. Lately (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 Software (OS)
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 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. |
| FCD |
The revised draft standard is published
again as Final Committee Draft (FCD) and
undergoes another ballot with the NBs lasting 4 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
achieved 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 |
Or the group may find out 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. |
| 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. Industries making end-user products, by definition, 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.
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 often not 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 serves your role in the
chain best. If the standard endorses your business model you will adopt
the standard, if it does not you will be antagonistic to it. 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.
|
