Turning the DVB ship around

We have reached a point where each new application sees the establishment of a new body to provide the framework in which to gather requirements, profile technologies, specify some of these, provide tools for interoperability and then move to implement. Why? Speaking for a moment as a representative of an organization (EBU) that must follow all these bodies to make sure that broadcaster requirements are included, I’d much rather have all the stakeholders in one group and then work on the different applications in that structure – with one membership fee.

The problem is – as always – people. Although the same companies are often involved, those active in one organization may not be involved in another. Looking around DVB, I see the same faces attending our group meetings. Sometimes their companies change, but encountering new people actively contributing to our work is rare. And yet their own companies have fostered the creation of similar organizations elsewhere to cover a specific topic, e.g. VR, DASH, etc. 

The ‘user experience’ we all seek to define is moving further up the OSI stack. Black-and-white TV sets linked broadcast TV channel selection to switching VHF frequencies – physical layer channel selection. This has moved to the remote control, and now is done via some form of application running on the receiving device. So, the reliance on the physical layer to determine user experience has been replaced by an ever-increasing reliance on software development.

This change has far-reaching impact on the organizations that gather stakeholders together to work on common technologies. Specifying the physical layer involved traditional standardization and big-industry engagement to fund the substantial development costs for the technologies and the silicon. Contrast that with open source software, where contributions can be made by anyone with a computer at home, and communities of thousands of contributors across continents and employers are common. This brings a different philosophy of how you go about developing applications, releasing them, testing them, etc. And what of the role of traditional standardization? Is there any?

Luckily DVB’s forefathers – some of whom are still involved by the way – thought of this and insisted that DVB was a “pre-competitive, industry-led, specification body working through consensus”. DVB outsources its actual standardization to competent SDOs like ETSI; it retains the flexibility to shape itself to best suit the purpose of producing specifications. So – at least in theory – DVB could adopt a new philosophy and a new approach if that would better address industry needs. The problem then centres on how you turn around an organization composed of hundreds of companies, and their representatives, who are happy doing what they are. Hmmm.

Although I am one of those dinosaurs around since the start of DVB, in 2016 when I agreed to stand for election to chair DVB, I did so on the basis that change was required at different levels in the organization. It will be hard to turn the ship around, but DVB’s heritage says we should try. DVB-I is all about bringing the linear TV experience to OTT. For this to work, fundamental changes must come to the way DVB does its work: working on interoperability, using open source tools and development techniques, permitting more failure, etc. Profitable OTT today is the preserve of very few organizations, and for it to become mainstream, substantial technical work needs to be done right through the delivery chain to minimize the cost, maximize the interoperability, and augment the user’s experience. DVB won’t develop OTT from the ground up, as it did with other technologies, for the reasons I outlined above, but it will play its part.

(Originally published in Issue 52 of DVB Scene magazine: https://www.dvb.org/news/dvbscene/issue/52)