IPTV’s Future — Part Two

You should have gotten the impression from the first installment of this article that IPTV is facing challenges. The main challenge already mentioned is that the bandwidth between a content provider’s headend and the subscriber’s screen is very difficult to manage, in terms of Quality of Service. The second challenge mentioned was the cost of the set-top box. The third challenge mentioned was the lack of standards.

Broadcast TV has well-defined and mature standards. Broadcast TV from free-to-air TV stations can be enjoyed without the need of a set-top box. Although viewers with an old analogue TV may choose to use a digital set-top box to receive digital TV broadcasts, all new TV sets have the standard digital receiver built in. The free-to-air broadcaster never needs to pay for, or subsidize, a set-top box for the viewer.

But TV services delivered over the Internet directly to the viewer have had no clear standards to follow. Apple does it their way. Hulu does it their way.

Traditional IPTV service providers have had to provide their own non-standard set-top box with its customised user interface and unique feature set. So now that we’re trying to eliminate the set-top box from the cost equation for the content provider, to what standards should we comply? TV content delivered as part of the normal Internet traffic requires the viewer to access it via an Internet browser. This requires a PC or a Mac, or an iPad, or an Android-powered tablet computer.

Until HTML5 comes along completely, there are no universal standards for the delivery of video or TV services over the Web. Microsoft will insist on WMV files as the delivery stream. Apple will insist on QuickTime streams. Others will insist on Adobe Flash streams and Flash code within the Web page that presents the A/V content to the viewer.

Until now, anyone wanting to stream A/V over the Internet had to encode the content to at least four different formats (WMV, QT, Flash, Real), and separately host the files on an expensive platform of media servers for each format. The more viewers you wanted to service simultaneously, the more streams you needed to pump out and thus, the more servers and bandwidth you had to pay for. It gets very expensive when you have a lot of viewers.

One of the big success stories for A/V content via the Web browser has been YouTube, which is based on Adobe Flash. PCs and Macs all support Adobe Flash as a browser plug-in.

But then Steve Jobs declared during the launch of the first iPad that Flash is a thing of the past and won’t be supported in the iPad. So now what? iPad users are denied access to millions of Flash-based Web pages, not just Flash-based video services. Huh?

We are all justified in saying to Steve Jobs and Microsoft and anyone else who wants to be a monopoly with their proprietary delivery mechanism: “Go jump in a lake! We’ll just stop using your proprietary streams and switch to something nice and standard, like HTTP streaming.”

We’ll just connect the Internet directly to the TV, and the TV will have a browser. It will hopefully follow some kind of standard like HTML5, and the video stream will carry its own player code in the header of the file as it downloads to the browser. The player code will execute in the browser every time we open a Web page that carries a video service.

We’ll never have to suffer the annoyances of the never-ending updates of Flash and QuickTime and Windows on our viewing device. The content provider can update the player at his or her end when needed. The video will carry the player code with it, every time we watch.

We viewers won’t need to install anything at our end. The browser will be almighty. And everyone will be happy. This isn’t a dream. It’s been available for at least a couple of years.

Vividas in Australia has been helping content owners deliver live broadcasts worldwide over the Internet via HTTP streaming for at least two years. The Vividas encoding of the A/V streams embeds Java code in the header of the streams and that Java code executes as a player in the browser for the A/V data packets that follow.

Unfortunately, Vividas is a small Australian company without the capital or marketing muscle to take the leader’s position on a global scale. But Google does have the necessary capital and marketing muscle. Now Google has bought Widevine, who has an http streaming solution like Vividas. So there’s hope that we can soon all say goodbye forever to the need for an installed “player” on our viewing device. With Vividas and Widevine, the browser is the player. It’s the way of the future.

HTTP streaming like that from Widevine and Vividas has adaptive streaming capability. This allows the player to choose the most appropriate version (encoded bit rate) of the A/V stream to download to the viewing device. This ensures that the available bandwidth for each viewing device is utilized to the fullest without being exceeded, thus, the problem of optimizing the QoS is addressed.

If HTTP streaming is “Exhibit A” in the argument for a browser-based, set-top box free and non-proprietary Internet television experience, then “Exhibit B,” Your Honour, is the confirmed availability of “connected TV sets.” Connected TV sets are the new LCD and plasma screens that have a built-in Ethernet port and a browser. Sony sells them. Samsung sells them. Panasonic, LG, and Toshiba sell them.

Some people call it “Smart TV,” but I’m not a fan of misleading names. I like descriptive names, and “Connected TV” is a good term because it describes what the TV can do that a normal TV can’t. “Smart TV” could mean any number of things, and “connected” isn’t part of the meaning of the word “smart.” Connectedness is the key thing.

With a connected TV, we don’t need a PC. We don’t need a Mac. We don’t need a set-top box. We just need our connected TV, plugged straight into our broadband Internet service. Or, if not the TV, then one of our existing, but necessary boxes outside the TV will do. The Blu-ray player is a good alternative. But, and it’s a big “But,” there’s still a problem.

The problem is that someone has to design the Web page for the browser in our connected TV, and define within that Web page the viewing feature set to be enjoyed by the viewer. The reason: the whole viewing experience depends on the design of the Web page and the features coded into it.

Want to pause the video? Technically, that’s no problem. Want a whole suite of “PVR” functions? Technically, that’s no problem either. The big problem is that someone has successfully attained patents for pretty much any kind of PVR feature and user interaction with the viewing device.

That someone is TiVo, and TiVo has been aggressively pursuing protection of their patents. By “aggressive,” I mean successfully suing Echostar for half a billion dollars because Echostar’s DVB-S set-top box has PVR features that TiVo claims were invented by them and protected by patents. Echostar lost. Echostar settled for half a billion dollars. Who will TiVo go after next?

What may now unfold in the television industry is a repeat of the money-wasting and innovation-stifling fiasco that currently bogs down the mobile telephone industry. Apple sues Nokia. Nokia sues Apple. Apple sues HTC. HTC sues Apple. And so on. The lawyers love it, of course. The lawyers are making hundreds of millions of dollars from all this activity. They never want to see it end.

But what about us, the consumers? We consumers wish it would all end very soon, because we’ll have to pay for all those legal costs in the long run. Those legal costs can only ever be recovered from the increased purchase price of our future products.

And what lies in wait for any engineer who has a bright idea to develop new products and applications for the connected TV? The “patent trap” is waiting for them, like crocodiles lurking beneath the muddy waters. Those crocodiles are called “patent trolls” in America. The term refers to people who want to get rich not by actually inventing or making something real and useful, but simply by acting parasitically on those who do invent and make useful things. The term was popularized by a senior Intel executive in 2001. This isn’t anything new to the world. But it is fairly new to the television industry, and TiVo has opened the door to patent trolling in our broadcast engineering daily life.

Worth noting: This author has been approached by pay TV operators already to help them prepare a defense against a potential law suit from TiVo because many pay TV operators, like Echostar, have been providing PVR functions in their set-top boxes for some time.

To really get the connected TV thing happening, we need two things:

First, we need a standard platform inside the connected TV. This is a browser platform that supports HTML5. Second, we need a safe development environment, free of the worry of patent trolls ambushing the project; and free of the financial burden of patent lawyers.

Broadcast engineers will need to help the lawyers explain and clarify the differences and similarities between the broadcaster’s new “player/PVR” running in the connected TV’s browser, and the things written in the nebulous gobbledygook of TiVo’s patent documents. Unfortunately, reading and trying to make sense of those patent documents is one of the worst jobs on Earth.

Therein lies the biggest challenge to establishing a delivery platform for television services over the Internet—and it isn’t a technical challenge. The technology is available now. Instead, it’s an efficiency challenge. We need to avoid burning thousands of hours in useless meetings trying to understand patent documents, and trying to help lawyers understand the technology.