Grace Hopper was one of the early pioneers of computing. She is quoted as saying "The nice thing about standards is that there are so many of them to choose from". The quote is also attributed to Professor Andrew Tanenbaum. Nevertheless, it is an accurate observation. There are a lot of standards!

We encounter standards everywhere, every day, from the power sockets on the wall to the way our mobile devices interact with one another. We should expect to see new standards describing how to interface with Artificial Intelligence (AI) and other smart systems in due course.

These articles focus on important standards for broadcast production and delivery in modern IP driven enterprises.

What Are Standards?

Standards describe the best practices for making compatible products from different manufacturers. For example, the dimensions of a connector and its pin connections, a data structure or an Applications Programming Interface (API). A standard could describe an entirely ephemeral entity such as a video stream or a file containing audio material.

Product manufacturing can be scaled up and distributed across many suppliers with standardized designs. This also facilitates spare parts provision and maintenance. The alternative would require every piece of equipment or software to be a bespoke and unique design. The costs of constantly re-engineering and re-inventing the same wheels every time would be prohibitive.

A Little Bit Of History

Standards have been around for a very long time. Much longer than you might think.  Here are some early examples:

Who Creates The Standards?

International standards such as those produced by ISO are the result of many industry experts collaborating through a process of consensus and approval. Each country supports its own committees covering specific areas of expertise feeding into ISO via a national standards organization. The standards are detailed and high quality but the preparation might take a long time.

Special interest organizations that operate internationally or regionally such as AES, SMPTE and EBU also collaborate to bring a high level of expertise to the process.

Smaller special interest groups (AIMS Media Alliance, AMWA and DTG) promote good practice with technical reports and recommendations.

Expertise is drawn from participating companies whose work informs the standards. A standard can be adopted informally by those companies to avoid any delay while it is being ratified.

Independent research laboratories and universities run projects to examine the viability of new technical approaches. The Fraunhofer Institute is a good example where the work they did on AAC audio compression facilitated the standards process.

Standards may evolve in an entirely different way by a large-scale adoption of proprietary technology. These de-facto standards are initially created by companies that make products to exploit them. Here are two examples:

• The Rich Text Format (RTF) document standard could only be used with Microsoft word processors at first. The format was easy to reverse engineer and is now widely supported by other applications. Microsoft have since published the specification for general use but it remains their intellectual property.
• Adobe PostScript code can be wrapped in a container to become a Portable Document Format (PDF) file. This has now been adopted by ISO as an international standard (ISO 32000) which is available free of charge.

A Taxonomy Of Standards

Organizing the standards into a taxonomy helps to see how they interact. Some large standards are divided into multiple parts, each of which might fall under different categories. This diagram illustrates our major areas of interest.

Video and audio standards are developed independently and integrated when a container describes how to embed and synchronize multiple tracks for streaming or broadcast transport.

Why Doesn't It Work Straight Out Of The Box?

Large and complex standards provide many alternatives for configuration with a lot of parameters each having a wide range of possible values.

Two companies might engage in building products based on a standard and intend that their products will integrate seamlessly with each other when they are deployed. If the standard allows any leeway for interpretation, these completely compliant products might not interoperate as expected if they use mutually exclusive implementations of the standard. Their customers cannot make them work together when they conduct the conformance testing.

This problem is caused by incomplete standards implementation on both sides. It is driven by pragmatism and budgetary controls on what is deemed to be a reasonable level of functionality.

Profiles & Levels

Complex technologies such as the AVC codecs introduced the concept of profiles and levels to simplify the interpretation of the standard.

An encoder does not always need to use all of the tools defined in the standard. Profiles describe a sub-set of the available coding tools that the encoder could use to compress the video. These profiles are designed around particular use cases to eliminate unnecessary features in the encoder implementation. The profile also provides hints to the decoder in the client player.

Levels define the picture size, frame-rate and bandwidth limits for the encoded bitstream to reduce complexity in the decoder.

Check that the profile and level support in your encoder settings is compatible with the decoder in your receiving device. Using higher profiles and levels may result in a better compression ratio but may also limit the range of devices that your content can be viewed on.

Standards Wars

Standards are sometimes weaponized for commercial gain. Perhaps by omitting support for a standard in a new product or by requiring customers to buy licenses to use certain features.

Organizations may build products that adhere very strictly to an accepted standard. Then they implement additional proprietary features and encourage developers to exploit them in their projects.

This serves several purposes. Firstly, they can rightly claim the moral high ground by declaring that they are wholly standards compliant - which is true. Once the proprietary extensions are deployed by developers, they are locked in to using that product. When a single maintenance release introduces a proprietary technology, removing it can take between 3 and 5 subsequent updates to replace it with your own solution.

The potential for using standards to lock customers into proprietary technologies still exists and needs to be anticipated to avoid it.

Glue-Ware

As an end-user faced with two incompatible products, you might still need to implement a work around and introduce bridging mechanisms.

Hardware interfacing devices to transform the signal from one format to another are widely used. For example, converting computer video output to a useful format so it can be integrated into the rest of the studio infrastructure.

IP based studios may still require a similar kind of virtual 'glue' to convert data streams or AV files from one format to another. The concept is similar but the implementation is quite different using apps and processes instead of hardware.

Classical hardware glue solutions tend to be instantaneous while software conversion may introduce some latency and delay the output somewhat. Hybrid solutions using the best of both approaches are also possible.

Overlapping Standards

Some regulatory bodies collaborate on specific standards topics. For example, CENELEC, ISO, BSI, EBU, ITU-T, JVT, MPEG and JPEG all share specifications for moving and still images. The output from these organizations leads to an ISO standard being published. Sometimes, a new standard is published and other organizations release essentially the same specification under a different name or number. The namespace is already crowded with acronyms and this can be confusing.

Risk Factors With Patents & Licensing

Check carefully whether a standard depends on patents before you commit to it. The authors may not have known which patents apply.

A useful standard might have patent licensing terms that make it very expensive to deploy. An open standards group might take the opportunity to create a compatible and patent-free alternative. This then becomes a de-facto standard that displaces the original. It is a major cost saving.

The standards development process tries to avoid this by not including patented technologies without an undertaking from the patent owner to license it for minimal costs to the implementer.

Submarine patents surface sometime after a standard has been widely adopted. This leads to a lot of unpleasantness. Be well prepared before committing to the use of a standard.

A potentially expensive situation arises where the patent holder attempts to monetize the usage (instead of the purchase) of equipment or software that includes their patent. This is a major problem for broadcasters who cannot be expected to pay a fee per viewer or per programme.

Careful architectural design can mitigate this risk factor. Web browsers such as Firefox rely on the operating system to provide support for playing AVC video. This is necessary because Firefox is an open source application with limited funding and the licensing fees are prohibitive. Delegating this to the OS means that only one shared license is necessary for all apps on that platform.

Conclusion

Standards are widely available but they are sometimes expensive to buy. They are often written in a deeply technical fashion which is hard to decipher. In the following articles we will drill down and examine the standards we depend on in broadcasting to unravel this complexity.

These Appendix articles contain additional information you may find useful: