Why Are Standards So Important?

Many different codecs have been invented. They tend to be based around similar algo-rithmic approaches because the engineers all go to the same conferences and read the same technical papers. The differences are in the fine points of the implementations and the choices the engineers make when constructing them.

Table 8-1 Codec Categories

Property Production codec Delivery codec

Compression ratio Low – typically 4:1 High – typically 50:1 or better.

Quality Perfect Good but may degenerate down to

sub-VHS quality.

Lossy Zero for some codecs, for Very others it is very minimal.

Bit rate 25 to 50 Mbps Down to 800 Kbps for video and 24 Kbps or less for audio.

File size 20 GB per hour Down to 0.4 GB per hour

Editable Yes Not really

Compositable Yes Only with alpha channel data

provided and as an overlay at best.

Key frames only Usually Almost never.

Conversion to other Easy Further significant degradation

formats likely.

Try several different manufacturers’ codecs to see whether one suits your content better than another.

The current state of the art for players is to deliver architectures that allow different codecs to be plugged in at run time. The players are separated somewhat from the codecs.

This is how it’s done:

A player provides a framework and a foundation with code that is necessary for playing back all video formats. This framework and foundation include the user interface (UI), for example, with its play and pause buttons, menu and file-opening dialogs, and general look and feel.

Once all the generic handling of a particular video format is dealt with, any special-ized code that deals with translating and decoding a specific video format is contained in a plug-in module. All of these plug-in modules support the same application interface, so the player can call for the same things to be done regardless of the format selected. The plug-in then deals with the specifics of a particular video-encoding or playback process, having been delegated with that task by the player application.

It’s a very neat concept and allows codecs and players to upgraded independently.

It creates opportunities for third parties to create their own plug-in modules or to make a player and then use a readily available library of plug-ins.

8.3.1 Open Standards Versus Proprietary Implementations

With an open standard, everyone gets to compete equally. Products are differentiated according to quality of manufacture, reliability, price, and functionality. With a proprietary implementation, you are locked in at the creative and consumption ends of the delivery chain. You have to justify for yourself whether this is good or bad. Decisions about this tend to be based on reach and market penetration of certain players or platforms.

Going with any of the proprietary codecs locks you into one or another company’s future strategy. You are entirely at the mercy of any decisions the company might make to immediately cease support of its player on a particular platform. Companies do that sort of thing, often with little or no warning.

Real Networks videois available everywhere; QuickTime is available on Mac OS and Windows but is not available on Linux without your using special tricks. Windows Media support is likewise available on Mac OS and Windows but not on Linux unless you use those same techniques to run Windows dynamic link libraries (DLLs) in a Windows emu-lation framework.

A DLL module contains dynamically linked library software written in Intel machine code and is designed to be shared between several applications to avoid duplication of the same code every time. Linux operating systems can generally cope with this quite easily by running the DLLs inside a framework, and provided they are on an Intel-based com-puter, everything is fine.

Mac OS systems use a completely different processor that does not natively under-stand the Intel code without the necessary software support being provided. The PowerPC chip in a Macintosh needs to run a translation or emulation engine to interpret that Intel machine code. It is possible (Virtual PC does it, for example), but it is not very easy to set up. Ideally, the software inside the DLL should be recompiled for the PowerPC, but this is not always feasible.

The availability and the quality of the user experiences are not dictated by the tech-nical ability to deliver them, nor are they defined by the resources available. The control-ling influence comes from marketing strategies that attempt to impact the market share of the underlying platforms. The codec and player manufacturers often use their products as weapons with which to beat one another. Real Networks offers its products on all the major OS platforms. Even though they don’t manufacture an operating system, they still make choices about how well to support a particular platform.

The MPEG standards are deployed far more widely. They are readily available and are played back even by most of the proprietary systems that would compete with them.

MPEG-1 was successful in its time and MPEG-2 has been resoundingly successful since then. H.264 is a worthy successor to MPEG-2 where it seeks to improve on the earlier state of the art. H.264 (MPEG-4 part 10) will be successful if the licensing terms for its use are made attractive enough. Early license arrangements for H.264 included per-copy fees and per-user charges, which the broadcasters found unattractive. The licensing process is still evolving slowly and the industry is optimistically anticipating terms that are similar to those under which MPEG-2 thrived. If program makers and broadcasters feel that patent holders are exploiting them unduly, they will not switch to the new standard.

More information about the H.264 licensing terms is available at the MPEG-LA and Via Licensing Web sites.

8.3.2 Why Standards Define Only a Decoder

In setting a standard, the MPEG working groups are seeking to provide interoperability between systems. Coders may be made by one company and decoders by another. If they both operate to an agreed standard then everything will plug together and work.

Therefore the standardization process typically defines the syntax of the bit stream to be decoded by the player. The specification does not usually mandate how that stream should be encoded. As coders become more sophisticated and powerful, they are able to squeeze more efficiency out of that syntax before they reach a point where no further improvement is possible.

Beware of lock-in with the coding platform and the client player tool. If they are both implemented correctly, you should be best served by getting each one from a different manufacturer.

MPEG-LA: http://www.mpegla.com/

Via Licensing: http://www.vialicensing.com/

MPEG-2 has improved in efficiency by a factor of about 2:1 since the original coders were introduced. Bit rates as low as 3.5 Mbps are routinely used for broadcast. There is still some room for improvements to the efficiency, but this is bounded by the need to remain 100% compliant with all the decoders that have been deployed. New opportunities for more radical improvement are presented when rolling MPEG-2 decoders out to “green-field” situations where there is no prior deployment, although these are also candidates for H.264 and VC-1codec implementation.

By defining the characteristics of a compliant decoder, the encoder manufacturers are free to innovate in any way they like, so as to generate the most efficiently coded repre-sentation of the original video source material.

8.3.3 Profiles and Levels

Certain features might be allowed or disallowed by defining profiles. This helps to man-age the complexity. Simple decoders check the profile of the incoming video and either attempt to decode it or display a message explaining why they will not.

Having defined a profile, the encoder must honor that and not create a coded repre-sentation that is any more complex than the profile allows.

Decoders are implemented up to a certain profile level and support content from the lowest to the highest they are capable of and everything in between. A maximally imple-mented decoder that supports everything MPEG-4 defines would be a very unwieldy and large piece of software that would be inappropriate for a lot of applications. A complete MPEG-4 encoder would be of no use in a portable device because you don’t need the more esoteric features. The portable device would probably not have the memory or compute power to cope with it anyway. So profiles help to keep the software implementation under control as well.

8.3.4 Better Compression Factors

In general, the more modern the codec design, the better the compression ratio com-pared with the original source material. Longevity of the codec also comes into play. The longer a codec has been around, the more tricks have been developed to exploit the encoder.

On the downside, newer codecs or upgrades to existing models will require greater CPU power to leverage the improved algorithms. This is less of a problem for the decod-ing in the client because the algorithms tend toward techniques that are very easy to decode. So you may need to upgrade your processing hardware as you roll out new encoders even though they target decoders with a longer lifespan.