I am really interested in the movements made by the Australian government on the digital media space. Although some parts of it don’t understand the Internet at all usually the public broadcasters -SBS and ABC- have some interesting initiatives regarding the digital frontier.

Last October the government published a paper titled “ABC and SBS: Towards a Digital Future” that invites the community to help planning the future for both stations. Recently they made the feedback they received publicly available.

I find it very fortunate that the document has focus on TV over the Internet and not only Digital TV. I’ve seem several broadcasters putting too much effort in Digital TV and not getting much back –except maybe by the illusion that the old business models will be retained. Here in Australia it feels that even the commercial broadcasters are losing interest in digital channels.

I am still reading some submissions –there are many- but the paper itself is very interesting. As a software developer interested in digital media I couldn’t help writing here my thoughts on the technical challenges in there.

Bandwidth & Scalability

The paper expresses concerns about the feasibility of larger-scale broadband TV initiatives.

The role of broadband
[…]
In contrast, the cost of providing bandwidth-intensive content to audiences increases with demand, particularly for media-rich content such as video. The more viewers who download content simultaneously, the more servers and bandwidth the broadcaster needs. Although cost factors will change over time, they need to be considered in decisions about national broadcasters’ use of services supplied through broadband Internet.

- Section 2: Harnessing new technologies to deliver service

Bandwidth is often a huge cost for broadcasters and interconnection fees represent a fair amount of operating cost. Also every single new user represents a hit in the infrastructure. There are many strategies to address this problem, let’s discuss three of them.

P2P Distribution

Although all kinds of data incur in high bandwidth costs the hugest amount is consumed by streaming or downloading of video and/or audio over the Internet. Streams and progressive downloads are heavy chunks of data that cannot be efficiently cached.

Probably the most promising technology for this is P2P sharing. To understand why this is useful let’s imagine the following setup for a web application.

In this scenario the clients connect directly to the server to get the content. The same content is served over and over and bandwidth is wasted.

In a P2P deployment we could have something like the following diagram.

In this case each user is not only a consumer but also a source to consume from. Just like Bittorrent and other P2P file sharing applications this creates a network of peers and minimises load and bandwidth consumption for the servers.

P2P is a very interesting technology but right now it is not much user friendly. It still requires some kind of software to be installed to perform the sharing in the user’s computer; standard browsers are not up for the task.

As an example, Joost used P2P and required a client application. To increase the user base they migrated to as a Firefox plug-in, but even that wasn’t enough and they gave up on P2P streaming.

This may change in a near future with the new version of Adobe’s Flash Media Server. Released last year, Flash Player 10 already comes with P2P-enabling features but we still need the Media Server to provide features that will enable secure P2P connections.

In my opinion P2P is not a feasible option for 2009 but a goal for the long run. Even if the infrastructure were available today it would require users to upgrade their Flash Player and that takes time for a large user base.

Third-Party CDN

The way most big players around the Internet deal with the bandwidth and load problems is to hire a CDN service like Akamai. Those providers have multiple edge servers spread over the globe that replicate your content. When an user requests the content she is served by the nearest available server, not only getting a better response time for the user but minimising connections to the origin server.

In my experience this is extremely cost effective for content that will be distributed across the globe but are not that effective when content will be delivered only in a given geographical area (except the US probably). The problem is that in a region there are often not enough edge servers to provide much benefit.

As ABC and SBS usually target the Australian community I can’t see much value in using a global CDN. The solution is still effective in that it balances load across multiple nodes but such a service is usually too and expensive and the benefits won’t justify the costs.

Custom CDN

As ABC and SBS target only the Australian market an interesting strategy may be to host video and audio servers inside the major ISPs’ network, creating their own CDN.

So we would get from this kind of deployment:

To something like this:

In this deployment the content producer has its own edge servers installed in the ISPs’ network. The traffic coming from the hugest ISPs does not have to leave their network, saving on bandwidth and interconnection fees. Whenever new content is created or updated it has to replicate that change across the edge servers. If some content is not available in the edge servers yet the users may be redirected directly to the main server.

I don’t know how open are the ISPs here but technically speaking this is a relatively easy task. As Australian broadband connections are often capped at some gigabytes it is already very common for ISPs to put ABC’s video player in their “freezone” so I don’t think it would be that hard for the broadcasters and ISPs to settle an agreement on that.

Depending on the distribution of users across ISPs this deployment can be extremely efficient. It won’t get rid of the bandwidth/load problem but can minimise it heavily. As an outsider I think that this is probably the best option to minimise costs and provide a good service as a public broadcaster.

In the next post I will write my thoughts on content, archive and community.