Television
The Internet is still in its infancy in terms of applications: new ones spring up every day. Some have been around for a long time, but we’re only recently starting to see them, thanks to bandwidth and latency constraints.
Television is open-ended, but joining the party is difficult because of a limit on the total available bandwidth for a given medium. Whether it’s terrestrial, cable or satellite, there’s a limit to how many channels can be broadcast at a time, even if there’s seemingly quite a lot of bandwidth to play with. This is why traditional television has been tightly-regulated (though many seem to have lost sight of this being the reason): having your programming carried by whichever medium you’ve chosen is, effectively, a privilege; if you wish to have a special chunk of spectrum reserved for your output, you need to commit to certain standards.
Architecturally, broadcast television involves middlemen. In the UK, Sky, the National Grid (thanks to its acquisition of Crown Castle) and Virgin Media are the main players in this game, with varying models. You can’t ordinarily receive broadcast television without involving such a middleman.
The Internet changes this. Not only does it offer enough aggregate bandwidth that anybody who wants to run a broadcast operation could conceivably do so, but the role of the middlemen changes to being just transit providers. If I want BBC programming, I can go to the BBC website and get it.
Television is standardised, though. I doesn’t matter whether I buy a TV Sony, Philips, Panasonic or some brand you’ve never heard of—it’ll work just the same. Right now, the closest we have to broadcast TV on the Internet requires proprietary software, even if it’s comparatively ubiquitous. This is wrong.
This is how it should work:
I visit the website of a broadcaster, and click a link to receive programmes. The link could be behind a paywall, or it could be e-mailled to me, or pre-programmed into whatever hardware or software I want to use to receive programmes. It’s just a URL to an entry-point, which is just a file in some standard format. Maybe it’s SDP, or XML-based, or something else that hasn’t been decided yet.
For broadcast (rather than on-demand), the “source file” is a list of live streams (“channels”) that my receiver can pick up. These could be RTP, or something else (perhaps leveraging peer-to-peer technologies). Multicast? Unicast? Anycast? Who knows. Open standards are key.
The next part’s easy. For a while, at least, MPEG 4 is the daddy: everyone from broadcasters to podcasters already use it. Depending upon how your channels are constructed, you could either have a single programme stream (containing audio, video, and subtitle tracks) or they could be separate streams. Stick to what you know, though: AVC (H.264) video, AAC audio. Everybody gets to play, that way.
Simple, right?
So simple, in fact, that it’s pretty much how Windows Media Player, QuickTime and RealPlayer have worked for years where streaming media’s concerned… except that the video and audio codecs have typically been entirely proprietary. QuickTime will happily take a URL to an SDP file pointing at a couple of RTP streams serving H.264 video and AAC audio. It can do that today. So can VLC, for that matter.
Maybe sometime this year, we’ll see some real efforts to broadcast (or simulcast) this way, instead of doing everything with Flash’s horrible unaccelerated proprietary rubbish.
