Six years have passed since I helped TVB Hong Kong launch its joint venture IPTV service. TVB was already a terrestrial broadcaster, and their joint venture had already launched a DVB-S pay-TV service to SMATV reception facilities around Hong Kong.
TVB rightly regarded the new IPTV service as a complementary extension to the existing pay-TV distribution platform. It would be an extension through which they could pass another million homes that were otherwise outside their reach.
It’s understandable for a veteran broadcaster like TVB to use the traditional vendors and technologies with which they are familiar, and that really means: “in which they have confidence.”
Since Tandberg compression was already in use for the DVB-S system in a statmux VBR configuration, it was an easy choice to select Tandberg again for the CBR compression system needed for the IP platform. Similarly, NDS VideoGuard was in use as the signal security solution on their DVB satellite service, so it was a “no-brainer” to extend the NDS encryption system to handle the IP streams as well.
The one area where we had to venture outside our comfort zone, was that of the IP set-top box. An IP set-top box is a completely different animal to a DVB-S set-top box.
Now DVB-S had already been around for 10 years when this IP service launched. A DVB-S set-top box is a very mature device. “Integrated Receiver Decoder” (IRD) was the other term in common use for the DVB set-top box. There were mature DVB standards for the IRD.
None of the above applied to the IP set-top box. It wasn’t a mature device. There were no standards beyond the IP multicast specifications, and that spec itself was still a work in progress.
The most extreme difference lies in the fact that the IP set-top box isn’t a receiver at all. It’s a computer terminal with a built-in MPEG decoder and an analogue PAL or NTSC AV output, all disguised as a receiver.
Grappling with all the issues that arose from the IP set-top box and its associated middleware consumed most of our time and resulted in most of the project’s stress. But like DVB-S, the IP set-top box was also the biggest single expense in the project budget. At US$100 each, it was going to cost $20 million dollars to provide the device to the first 200,000 subscribers.
The project bottom line, however, was that we were broadcasters trying to make an IPTV service look exactly like a DVB-S service from the subscribers’ point of view. That fact drove a lot of the design decisions and product choices.
Following the successful launch of TVB’s IPTV service in July 2005, a lot has changed in the world of IP distribution of video signals. In fact, a critical mass of people now believe that IP networks are the way of the future for the distribution of some types of television content.
To smooth the way for more television to consumers over IP networks, we have to find ways to reduce the cost of the set-top box, or to eliminate the need for that device altogether. We also must make TV over IP more resilient to the typical inconsistencies in network bandwidth and latency, which occur between the content source and the subscribers.
In the earliest days of IPTV—I think it is still “early days” even now—it was mostly telcos who set up and marketed IPTV services. That’s because the telco could afford to allocate the large and constant chunk of bandwidth required on its network backbone to all corners of the metropolitan area.
At normal leased line rates, it isn’t viable for an outside content owner to lease data circuits between their video headend and a million homes. That’s why most IPTV service providers are telcos, because they own the network. Besides, once the network backbone was totally converted to optical fibre, the bandwidth was there anyway and they needed to find a profitable way to utilize it.
As a result, telcos decided that they had to become broadcasters. They had to set up a video headend (a content preparation and playout system) and then multicast all the television “channels” as streams of encrypted IP data packets, via a permanent allocation of data bandwidth on the network backbone right up to the digital subscriber line access multiplexer (DSLAM) under the subscriber’s building.
The subscriber’s IP set-top box could then communicate with the DSLAM in order to “leave” and “join” any particular MPEG stream within the bundle of streams passing the DSLAM.
It was all part of the telco’s grand plan called “triple play,” a term that describes a telephone, Internet and TV service bundle, all on one bill. Since the telco owns the network, they can manage the traffic and the bandwidth and make the bundle work as a reliable bouquet of services.
In the U.S., what the broadband network owners hadn’t factored into their bandwidth planning was the unexpected heavy load from peer-to-peer (P2P) network traffic. Peer-to-peer network traffic was largely carrying rich media downloads, legally or illegally, and real-time gaming graphics data. P2P traffic was threatening to choke the telcos’ networks and it challenged the telcos’ ability to guarantee the required Quality of Service (QoS) for their other broadband Internet services.
Comcast, in the United States, got into serious trouble with the FCC because they tried to throttle the P2P traffic, in an attempt to maintain the QoS for their TV data streams and other services. The FCC tried to stop Comcast from throttling traffic on their network, but a recent court ruling declared that the FCC doesn’t have the legal right to stop Comcast from throttling P2P traffic. The problem has now moved into a state of limbo while legislators work out the next course of action (at this time of writing).
The U.S. situation is actually more complicated because there’s usually only one physical broadband network available in any given geographical area, with the other competing ISPs having to lease capacity from the owner of the incumbent physical network.
In order to prevent monopolistic or discriminatory behaviour, the U.S. government has declared a policy of “net neutrality” whereby the owner of a network must openly and fairly hire out capacity to competing ISPs. That, in essence, makes it harder for the network owner to fully control the traffic on his own network, if the law states that certain kinds of traffic can’t be throttled by the network owner at his own discretion.
We didn’t have this problem in Hong Kong because each physical network can reach pretty much any home. It’s really only the last 50 to 100 metres in some apartment buildings where maybe one telco has to get permission to use the cables of another telco in that building. But for the most part, each telco can run his own cables to each apartment, right alongside the competitor’s cables (or fibres, as the case may be). And each telco can freely allocate the bandwidth in their network in whatever way they see fit.
Looking around the region, then, or the whole world for that matter, the future of IPTV has a lot to do with the local laws and regulations about broadband networks. For example, Australia is rolling out their National Broadband Network (NBN) while the parliament is still hotly debating how it all should work and what it should cost.
That makes for a very volatile and high-risk environment for someone who plans to build an IPTV service in that country. If the current government is voted out at the next election, the new government will try to “change everything” about the NBN, according to all the noise they’ve been making about it in past months.
Meanwhile, if the net neutrality principle gets a foothold in all countries, and the owner of the physical network can’t exercise control over the bandwidth utilization on the network, it becomes difficult to plan for IPTV services where robustness of the IP streams into the home must try to meet the QoS standards for what viewers know as “television.”
Imagine if terrestrial and satellite RF broadcasters didn’t have their guaranteed allocation of spectrum, but rather, the RF channel allocation had a variable bandwidth on a day-to-day or hour-to-hour basis, like end-to-end Internet bandwidth happens to be.
Despite the above-mentioned challenges, more and more IP-delivered video services are surfacing. In the U.S., Apple, Hulu and Netflix have set the precedent for official delivery of television shows and movies either as streamed services or as downloadable files. The era of video rental shops that you can physically walk into has officially ended. What Apple did to the music distribution world with iTunes, they now intend to replicate with TV shows and movies.
Google, too, sees potential for the TV over IP business. Their Google TV website says it all on the splash page: “TV, apps, search, and the entire Web... together at last.” And then on the next page, they declare the big plasma or LCD screen in the home as the centre of the Google TV universe. So, in essence, they are really bringing the Web to the TV, but making it all appear to be seamless with the television services.
Thanks to the basic principle of net neutrality, anyone with content should feel free to deliver it to subscribers over broadband networks; not as a dedicated chunk of allocated bandwidth, but as a normal part of daily Internet traffic. “Over The Top” (OTT) is the term telcos use to describe TV services carried as part of normal Internet traffic, rather than as a dedicated and carefully managed IPTV trunk “under” the metropolitan area broadband network.
Having TV services distributed as part of normal Internet traffic is a little bit like trying to establish a 24-hour radio station in the CB radio band. It might technically be possible, but there are practical limitations, mostly to do with the behaviour of the consumers who utilize that communication band.
Just as the sources of television content are now diversifying, the destination devices for the content are becoming equally diverse. Google TV declares the home TV screen as the centre of the IPTV universe. But Google also has an interest in Android-powered tablet computing devices and smartphones as well. Apple sees the home “TV set” and the iPad as the two important screens, with the iPhone thrown in for good measure.
So let’s define three important screens: Large, Medium, and Small. They all need to be catered for in a world where TV is delivered over IP networks. And within those three categories we can subdivide them again into “fixed” and “mobile.”
Regardless of the destination device, once TV services become part of normal Internet traffic, there are no guarantees for the bandwidth available between the video headend and the subscriber’s viewing device. With such uncertain dynamics and market forces at play, what can we technologists do to build a reliable technical platform for IPTV?
What we need is a universal content stream that can find its way along any path between the headend and any type of screen. This is where “HTTP streaming” and “adaptive streaming” are important terms that broadcast engineers need to know more about. More on that later, in Part II of this article.
