IPTV/VoD: solving the home wiring problem
You can expect to find different models from Belkin, Netgear, Linksys, D-Link, Actiontec and many more. And the bad news is that despite being built to comply with standards (PPPoA, QoS etc), they all have a complicated, unsynchronised mess of different features that don't have a hope of being pulled together cohesively. Most desperately need firmware upgrades, have ugly, incomprehensible and unusable admin interfaces, break down with alarming regularity and are OEM tin cans made in China from the cheapest components available.
The one feature they need, QoS, either isn’t there, or is implemented in a meaningless way. The router is the broker of all services into the home – a bottleneck and control gateway that is crucial to the satisfactory deployment and maintenance of high-value services.
This chaos needs to be resolved somehow, which generally means mandating, and only supporting certain hardware. The biggest ISPs use this (not having to go out and choose what equipment to use in your home) as a selling point, but the smaller providers work at recruiting the more specialised market sectors – small businesses, and early-adopting techheads. BT tends to enforce the use of their own router, Wanadoo requires you to use a LiveBox, and Homechoice supply you with a set-top box that includes a DSL modem. In most other ISP customer bases, its unusual to find more than 15 per cent of the raw subscriber base that definitely use the same hardware. The flexibility of plurality has its limits, and change invokes them very quickly.
One of the first questions and preconceptions of those who are curious about IPTV is how similar it is to streaming video on the web, or 'Internet TV'. The answer is that the process of streaming the audio and video uses the same mechanism (RTP/RTSP), but the environment in which it is transported is strictly controlled by an ISP, never going onto the public internet. Being unicast at crappy resolution, streaming video on the web is abjectly awful and bottlenecked at every point – even the bravest of souls is tempted to commit hari-kari when the dreaded "Buffering…" appears on screen. No matter whether it's Real, Windows Media, Quicktime, Flash or anything else, it’s always dreadful. IPTV has a barrier to climb in the form of this particular preconception before anything else.
You can’t be watching TV and have your picture break up because someone else in the house has switched on their BitTorrent client and starting eating up all the bandwidth. Video signals over IP are extremely sensitive to jitter, packet loss, delay and many other conditions that exist in a normal network. This isn't such a problem when browsing web pages, or even for phone calls. People's tolerance of problems on their TV is very, very low in comparison to their PC. In fact, most even expect their computer to do something unpredictable and leave them totally confused (the infamous BSOD, or "Blue Screen Of Death"” being a prime example of this). The game isn't uptime of five nines, it's 100 per cent reliability. You don’t get to mess up even once.
Different types of TV signal from different broadcasters have differing bandwidth requirements. Most IPTV is now transmitted or encoded in an MPEG-4 codec variant (H.264 or Windows Media 9 typically) at the highest possible quality. For standard definition this means 1-4Mbit/s, and 6-10Mbit/s in high definition. If you're prehistoric and still using MPEG-2, the figures are 4-6Mbit/s and 25-30Mbit/s respectively. Encoding can be done using an average bitrate (ABR), but is handled efficiently by intelligently determining when additional information is needed in the stream – for example water, cartoons, sports and high action sequences require enormous detail and therefore more bandwidth. Scenes where there is little movement (e.g. talking head-style discussion or still shots) need hardly any bandwidth.
Maths geniuses will have worked out by now that trying to get TV down a phone line is a lot easier using MPEG-4 and high line speed DSL connectivity than using MPEG-2 and plain old vanilla DSL. It can be a real struggle when most people's lines aren’t close enough to their exchange to have enough space to reliably handle digital TV. Standard DSL, such as the new BT Max product, does 8Mbit max as ATM line speed and nearer to 7Mbit/s at the IP layer. You can fit a 1 standard definition video stream in it with very little room for much else. ADSL2+ can handle 3 SD/2 HD channels and VDSL2 many, many more at close range (and ADSL2+ rates elsewhere). Both have the limitation of distance, but greater bandwidth at the last mile is always beneficial. No one who has ever deployed this technology will ever tell you that the beer-mat maths actually work in the real world.
The key issue here is reliability. Just because a connection can theoretically accept large quantities of real-time data doesn’t mean it will arrive properly. Rats chew through cables, water shorts out electric machinery and wiring suffers evil 'crosstalk' when it's bundled together in street cabinets. TCP as a protocol is extremely aggressive and will seek to consume the very maximum bandwidth it can, meaning controls are essential. A DSL signal is typically encapsulated using the ATM protocol (using PPPoA as the carrier layer) up to the front door, where it then is translated into IP by the home router. That has a larger implication when putting in controls – the last mile speaks a different language than the home and backhaul networks it is sandwiched between.