DVB – A Historical Look at a Non-Standard Standard

In September 2013, the Digital Video Broadcasting Project (DVB), celebrated its 20th anniversary. Broadcast Projects´ associate David Short looks back at how this ´non-standard´ standard catalysed the digital TV broadcast sector.

DVB, a project dedicated to creating open technical standards for the worldwide delivery of digital TV and data services, has been the standard on which the digital TV broadcast industry has been built since 1993 when the project was first launched. It incorporates MPEG for video and audio compression and transport packetisation.

The interesting thing about DVB is that it has no compliance testing regime. It is left to device vendors to declare that their devices conform to relevant DVB standards, which are often quite flexible. This means that, unlike many standardised items (eg, IP networking devices, GSM or 3G mobile phones, DOCSIS cable modems, ISO shipping containers, JP4 jet fuel, etc) a DVB receiver is not guaranteed to work on any DVB network. In fact, it will probably only work on the network it was designed for. So, the question is, why has DVB been so successful if it isn’t really standard?

Some of the “non-standard-ness” of DVB is explained by the widespread use of conditional access (CA or CAS) which means that a set top box (STB, the most common form of DVB receiver) can only decrypt signals in the network for which it was designed. This is usually a side effect of CA systems that put bespoke security software or hardware in the STB. Although the primary intention is to provide protection for the content, it usually means that the box will only work on its home network.   Some CA systems do intentionally bind the STB to their “home” network like a phone is locked to a 3G network and for the same reason – to protect subsidised boxes. However, even in the “free to air” market, the point is still true. It is unlikely that you can move a box from one free network to another and have it work properly, if at all. (I am leaving aside the fact that DVB covers satellite, terrestrial and cable transmission – interoperability between these types of transmission media is not possible due to physical differences.)

TECH-Greco_P1190728-tall

Talking about stacks!
Standards can achieve interoperability without formal compliance. For example, the IP stack “grew up” over a couple of decades and there is a de facto standard for interoperability that is now driven by large vendors such as Microsoft, Cisco and Apple – also the Linux Kernel. If you want to sell an IP device, you had better make sure that your IP stack works with all of the above!

Now let´s quickly look at the technical reasons for non-interoperability (and their commercial drivers) and then why DVB is still a successful standard.

DVB has no compliance regime and this means that networks can follow a loose definition of the standard.  DVB has many “options” regarding the exact implementation. For example the language can be indicated at the channel (service) or programme (event) level. In addition to these options, DVB also allow private data packets and private data within its own tables. These have given significant flexibility to the standard and allowed extensions that were probably not envisaged when the standards were created eg, interactive TV, data to enhance PVR use – such as series linking.

The downside to freely allowed extensions is, of course, that we build “silos” of non-interoperating networks and boxes. The way the industry has responded is different for pay vs free networks.

For pay operators, it is necessary to integrate a CA system into each model of STB and make it work with the network. By design, the CAS will not work with other networks or boxes. The options and private data allowed in the DVB standard are integrated and tested as part of this process for each new STB an operator launches. Of course, there will be some leveraging of existing software stacks unless the new box has a completely new architecture. In fact, many networks will go further than using the “allowed” option and use DVB in a non-standard way. A favourite trick is to use non standard addresses (PIDs or packet IDs) for the tables that define the network details and service list (the NIT, BAT, SDT and EIT for all your DVB nerds out there!) This is usually done to bring on a new population of boxes that, for some reason, can’t share the data structures with existing boxes. The “non-standard” addresses are hard wired in the new boxes in the same way that “standard” or “well-known” addresses are hard wired. Although this arrangement is technically not “DVB Compliant”, who cares? The boxes work, the operator has an easy fix to a hard technical problem and DVB still lets them put stickers on their boxes (if they pay the membership fee!)

In the case of free-to-air networks, the business model is for broadcasts to get funding from a licence fee or advertising and for STB vendors to sell (usually unsubsidised) boxes direct to viewers. This means that there must be an open process to define the “air” interface. Free operators or sometime the relevant regulator, usually take the approach of writing a “profile” of DVB which ties down the options, private data, etc to give an interoperable standard. Usually this is combined with a compliance regime and vendors must pass a set of tests before they are allowed to use the relevant logo on their boxes. Examples of this arrangement are Freeview in the UK and TNT in France. In the UK, the “profile” is the D-Book produced by the Digital TV Group (DTG.) One of the private extensions added by the D-Book is support for “Logical Channel Numbers” (LCN) which are the channel numbers given to viewers. Strangely this is not supported in native DVB.

So, if it’s not a standard, why does it matter and why has it been so successful? It’s worth giving a quick potted history of DVB for those of you who are not in the DTV industry. DVB was launched as an offshoot of the European Broadcasting Union (EBU), is a club of European public service broadcasters (best known for the EuroVision Song Contest, but more importantly for the huge amount of backroom technical work they do.) DVB was the first “open” standard for digital TV broadcast (although DirecTV had an in-house standard that proceeded DVB.) Today, it remains the most widely used with almost ubiquitous use in Europe and significant use on all other continents.

We have spent quite a lot of time talking about the parts of DVB that are not standard and they are mostly related to metadata – data about the structure of the networks, services and event lists.

Some other important things to take into consideration are the interoperable standards that do work together with DVB, albeit de facto.

IBC 2011These include:

  • the MPEG encoding via profiles eg, main profile at main level (MP@ML) for legacy SD Video
  • MPEG transport streams which define the packet structure for all DVB transports (even if the video is using newer coding profiles)
  • Modulation. This changes to optimise throughput for a given medium eg, DVB-C for cable, DVB-S for satellite and DVB-T for terrestrial. All of them have a second generation version that use newer modulation techniques and the extra processing power of modern chips to get better line coding efficiency.  These are DVB-C2, DVB-T2 and DVB-S2.

The significant thing about the list above is that decoding, packet handling and demodulation all take place in hardware. So if these are fixed, chipmakers can produce one DVB version of each component and then let the software boys and girls worry about customising the metadata level specific to each local network. Of course, you can’t mix cable, satellite or terrestrial in a box (it was tried once but it’s not widespread!)

Also, technologIBC 2011y moves on, so you can’t use a legacy box to watch HD and/or MPEG-4 (which aren’t always the same thing!)

Obviously, having a set of standard chips to choose from drives costs down, quality and functionality up and is a pre-requisite for a successful industry. However, that’s not the whole story. DVB has given a generation of engineers, developers, testers and project managers a framework to learn and think about digital TV. If there had not been a dominant standard in the early days of digital TV, it would have been that much harder for people to move between projects and employers and for the industry to talk together at conferences. Remember the early days of computer networking with DECNet, SNA, Novell, IP, etc?

This critical mass of skills has allowed the industry to grow and develop. Now DVB has competitors such as DMB, ISDB and ATSC but the concepts that DVB established largely map across to the other standards and are now second nature to practitioners in any case.

-David Short