Can we improve MPEG standards’ success rate?

Can we improve MPEG standards’ success rate?

Introduction

I am very proud of the high scientific level of the work that MPEG does with its standards. I think that many universities would enhance the value and effectiveness of the education they provide if they took an MPEG standard, not necessarily a successful one, and have students redo the same process that led MPEG to develop that standard.

Because of their high scientific value so many MPEG standards have been wildly successful, as The impact of MPEG standards tells. More standards – more successes – more failures tells about the other side of the coin and argues that as much as certain products from companies are successful and others less so, some MPEG standards have a level of success that does not match the expectations of the experts who developed them.

What went wrong in those cases? My answer to this question is that not necessarily something went wrong and I will try and explain why.

Standards and market needs

MPEG is an excellent environment to develop standards because it has hundreds of the best experts in its field of endeavour. Several hundreds more are in the laboratories who do not, or only seldom attend MPEG meetings. MPEG experts make their proposals of new standards because someone in their companies has envisaged a business enabled by the idea they propose. MPEG is very receptive of new proposals and has a very good process to  develop requirements for a new standard. However, that assumes that the market needs that standard because those who develop the requirements are often the same technical people who will later develop the standard.

Let’s see how another successful environment developing specification – the Digital Video Broadcasting (DVB) project – handles the matter. A proposal for new work goes first to the Commercial Module. If the proposal is not accepted by the Commercial Module, it will not be considered by the Technical Module.

This is possibly a good arrangement for DVB, a group that works apparently in a similar area as MPEG. Similarities, however, may be misleading without considering the entire picture.

  1. MPEG addresses matters regarding the compressed digital representation of media. Therefore MPEG is a “horizontal” committee, while the DVB addresses the entire broadcasting protocol stack, from the physical layer – e.g. DVB-T (for terrestrial), DVB-S (for satellite) and DVB-C (for cable) up to the application layer (e.g. the Multimedia Home Platform or MHP).
  2. MPEG hosts experts from all industries with a stake in digital media while DVB members are predominantly companies interested in broadcasting applications. In all fairness . the separation of broadcasting from other ICT applications in an age of convergence is no longer what it used to be at the technical level, but the business context is different and this still matters.
  3. Some MPEG standards have the luxury of being “long term” (say, 5 years). Examples are the investigations in 3DoF+ and Point Cloud Compression, the former of which is on the launching pad to become a standards and the latter pretty close to the end. Both activities have been incubated for some years. DVB is more short-term oriented and does not want to invest resources in projects that may pay off only years from now.

MPEG already tried something

In 2015 I proposed to MPEG to establish a new activity with the preliminary name of “Industry liaison” and I even developed a concept of the new organisation of MPEG groups (Figure 1). My idea was that this activity could become a new MPEG group, if proved successful.

Figure 1 – Concept of MPEG organisation with industry liaison

Rob Koenen, then of TNO and José Alvarex, then of Huawei America (both tell you something about the dynamics of MPEG experts) were kind enough to take the challenge. They and a group of interested members created a presentation of MPEG activities.that was used at several exhibitions and conferences, e.g. NAB and SMPTE, to stimulate reactions from industry participants. The last slide of the presentation asked three questions:

  • Which needs do you see for media standardisation, between now and years out?
  • What MPEG standardisation roadmap would best meet your needs?
  • To accommodate your use cases, what should MPEG’s priorities be for the delivery of specific standards? For example, do you urgently need something that may enable basic functionality now, or can you wait for a more optimal solution to be released later?

That was a big effort and I am thankful to Rob and José for spending so much effort for the good of MPEG. Unfortunately the goal to create a momentum to the process of getting more information from industry about their needs was not achieved as a continuous and self-sustaining process.

This does not mean that the effort was not useful. Today Rob is in charge of keeping up to date the MPEG Standardisation Roadmap, a public document that provides a graphical representation of the entire MPEG work plan and its timeline, a very important function as Figure 2 related to March 2019 shows.

Figure 2 – MPEG Standardisation Roadmap

Let’s give it another try

Why did the proposal not work out as expected? One reason is intrinsic to the MPEG constitution. MPEG is a large community of experts, but there are very few if any market people, even from the larger companies. We have tried and reached out to the industry but we have been unable to get market people to join MPEG.

My assessment is that, as long as MPEG remains what it is, a wonderful forge of new standard technologies, it will be hard to achieve that goal.

In Which future for MPEG? I have proposed that MPEG become a Subcommittee (SC). This change of status is not intended to be a “promotion” but a better set up that allows MPEG to play a wider role than purely technical.

My proposal is reproduced here in an improved form as

Figure 3 – Proposed new structure of MPEG as an SC

The “Market needs” box represents the new attempt at getting market requirements into the MPEG process. However, it is quite different than Figure 1 because in that figure the Industry liaison function precedes Technical requirements, while here they work in parallel.

How should this new arrangement work?

Proposals for new work should be assessed both from their technical feasibility and their market value. The Technical requirements and Market needs Advisory Groups (AG) should make their assessments driven by “how much technology supports this proposal” and “how much market needs this proposal”, respectively. So, in a sense, the two groups will co-compete. In general Technical requirements will be for innovation, while Market needs will be for conservation. But it will not necessarily be always like that.

These groups should have, as all MPEG groups do have, joint meetings to align their views and they should, if they can, develop a single report. If that cannot happen, there will be two separate, possibly conflicting, reports. In both cases the SC plenary will asses the report(s), take responsibility and make a decision on the basis of a country-based vote.

What will be the meaning of this vote? It should certainly not be a replacement of the vote taken via ballot on a New Work Item Proposal (NWIP), but a vote on whether MPEG should acquire – via Calls for Proposals – the technologies that may be used to develop a standard. The actual NWIP vote will only take place when the Technical requirements AG and the appropriate WG(s) will agree that there is enough material to develop a standard.

So far I have talked of Market needs and Technical requirements having a passive role, i.e. waiting for proposals coming either from experts (as it has regularly happened so far) or from National Bodies.

The operation of the AGs, however, needs not be constrained to be in response to a proposal. They could very well, by their initiative or because they have been requested by the SC plenary, to engage in the study of new areas. Such studies should always be conducted from the point of view of what technology enables and what market needs, or what could be the reaction of the market to a certain standard technology.

The mission of the Market needs and Technical requirements AGs should not be considered accomplished when the NWIP has been approved and the development of the standard starts. MPEG must have the means to review the steps that have brought to success or failure of a standard.

You should not expect that this post mortem analysis can be done 6 months after MPEG has released a standard for publication. It is not unusual that 6 months after release by MPEG a standard has not been published yet. It is true that the world a quarter of century ago moved more slowly that today, but MP3, released in 1992 became a product only 5 years later, MPEG-1 Video (with MP2) became a product at the end of last century. We are talking here of an infrastructure to be put in place now whose first results we can probably see in five years.

Conclusions

This proposal should not be seen as a roadblock to the capability to innovate that MPEG has shown to be capable of in the last 30 years.

It is usually said that if commercialisation costs 100, product development costs 10 and research costs 1. I add that, probably, an MPEG standard costs a company 0.1 (excluding research because that is already accounted for).

So this proposal is not about cost saving. It is about making an excellent and successful MPEG process better, without running the risk highlighted by Monsieur de Montesquieu: Le mieux est l’ennemi du bien (better is the enemy of good).

MPEG is known for its innovative standards, but it should be better known for its process innovation.

Posts in this thread