As I understand it, IPTV is defined to be a live television service delivered over multicast (usually RTP) over a broadband Internet connection. Multicast has an advantage over normal traffic (“unicast”) because it avoids the duplication of traffic. Only one copy of the data is ever sent.

TPG currently offer 19 channels over an IPTV service, and TransACT allegedly offer over 50. iiNet is “on the brink of IPTV launch”. There are rumours that Internode are investigating something similar too.

That last paragraph should have triggered alarm bells in your head. It did for me, but maybe I’m just a cynic. Let me explain.

I asked myself: why are the ISPs providing the IPTV service? It sounds wrong to me. I’ve tried to come up with an answer, and my conclusion is that it is because of two reasons: (1) infrastructure (multicast is virtually non-existant in most production networks) and (2) content lock-in.

Having the ISPs provide the infrastructure for the IPTV service (marketing, encoding, distribution, etc.) means the ISP will likely sign a contract to exclusive usage rights with the TV partner for each channel they will provide. If iiNet sign an exclusive deal with Sky News, they sure as heck ain’t going to let Internode or TPG also put the content on their networks.

The infrastructure would also be duplicated. Each ISP needs their own TV receiving equipment (likely a few satellite dishes on top of their data centre), encoding equipment, marketing, private IP multicast network, and whatnot.

With regards to content lock-in, this will also mean that the ISP you choose to use will determine what IPTV channels you are able to watch. Conversely, what IPTV channels you want to watch will determine which ISP you will sign up with.

That sounds all rosy, until you consider that I am not restricted on what websites I can visit based on what ISP I am with. I can watch YouTube or ABC iView from any ISP in Australia. Sure, some ISPs offer better services than others, faster speeds, or more reliable connections, but it’s just the one Internet. This is because the ISP is not in the content provider role. They are merely the gateway to the Internet — the Internet service provider (now where have I heard that term before?).

The way IPTV looks like it is heading is shifting the ISP onto the content provider role. As I’ve already said, this means the service is delivered over the ISP’s private network, available exclusive to that ISP’s customers, and not over the Internet. That’s a Bad Thing™ in terms of net neutrality.

If an ISP “rebroadcasts” content from an IPTV channel that another ISP has signed an exclusive deal on, that would be a copyright violation.

But that still doesn’t explain the title of my post: “Multicast versus IPTV”. The above isn’t actually the crux of what I wanted to get at (apologies to the reader if you’ve managed to read this far in great detail).

I’m supportive of multicast in general. Combined with IPv6 (each /64 subnet has a corresponding multicast subnet), multicast opens up the doorway for anybody to serve high definition audio and video to the Internet at large without the need for exorbitant amounts of bandwidth up their sleeve.

But that’s public multicast. These “IPTV” solutions will be, and currently are, deployed on private multicast networks. On the plus site, private multicast networks mean it is easier for the ISP to deploy the infrastructure — it’s much easier to only have to worry about your own network, than also have to worry about interfacing with others. But it also means less incentive to deploy a public multicast infrastructure, and less incentive for content providers (such as TV networks) to provide their services over multicast themselves. It’s a chicken-and-egg problem.

We don’t need ISPs to “provide IPTV services”. We need a decent multicast network (preferably IPv6) that all Australians can access, so that TV stations themselves can provide the multicast streams with the knowledge that a large percentage of Internet subscribers are able to access their content, and that channel availability discrimination does not occur based on what ISP you choose to sign up with.

That’s the crux of what I’m getting at. I’m sure someone will come along and say “but but but…they have a right to sign exclusive contracts and deliver only over private networks”. My response to that would be that just because you have the right, doesn’t make it right. Nor left.

Thoughts?

But one thing struck me over and over again: the Bunnings ads had horrible MPEG rendering artifacts at the end of each one. At first I thought it was due to poor reception, but this weekend we completely re-wired our house’s coax connections with quad-shielded cabling to our TV antenna and bought a new masthead amplifier, which greatly increased our signal quality.

(And no, we didn’t replace it just to watch the Bunnings ads.)

But this remained:

Yuck. That is definitely not signal loss — that’s crappy encoding. I can give people a (non-reencoded) AVI file of the original if they want proof.

I think it’s mainly a result of the fact that the ad is being rendered at 1080i with the outdated MPEG-2 codec. We desperately need an upgrade to H.264, or even better, Dirac.

To update an existing Python-iView system, change to the directory where you installed it, and run:

$ bzr pull

Then, to support the new SWF verification ‘feature’, you will need to download and install rtmpdump, and install the resulting rtmpdump_x86 executable into somehere like /usr/local/bin.

(For those of you content with having their videos cut out every 8MB, feel free to continue using FLVStreamer — Python-iView will try both FLVStreamer and rtmpdump.)

If you don’t already have Python-iView, see the original post for instructions on how to get it.

However, the iView website has some major problems:

• It depends on the use of the Adobe Flash plugin, which is proprietary software, which means that only changes or fixes for bugs in the plugin that Adobe approve of can be applied.
• Flash only runs on Windows, Mac OS X, and x86 (32-bit or 64-bit) Linux. (e.g. our 1GHz Apple eMac running Linux has a PowerPC processor, which Adobe have chosen not to support, and thus cannot access iView, but would otherwise be powerful enough to play the videos.)
• The videos must be watched in the browser inside Flash, which is a lot of overhead compared to a simple media player like VLC. iView is too slow on older or less powerful computers. (e.g. iView is so slow it is unusable on my ASUS Eee PC 901, even though it internally only uses 640×480 FLV video which should in theory be playable by any computer made in the last 10 years.)
• Videos must be launched from within the web browser, and cannot be watched offline (e.g. downloading in advance for a long car trip). Though the ABC offers a download service for some of its programmes, it is not as comprehensive as the iView programme. Nor can iView programmes be downloaded for the purposes of fair dealing (e.g. quoting certain parts in journalism or interoperability — see points about Flash being proprietary above).
• Not everyone has a fast Internet connection, and cannot watch the videos in real-time. You can get much smoother playback by downloading a video in advance and watching it once it is finished.

To address this, I wrote the open source (GPLv3 — see license) application Python-iView, which does two main things:

• Allows you to browse the iView programme outside of the browser (from a GTK+ interface).
• Allows you to download episodes to your hard drive in their original FLV format.

You can then play the resulting FLV files in a media player such as VLC or Totem. Because certain videos are formatted by the ABC in an anamorphic widescreen format some videos may appear squashed. If this happens, make sure to select the 16:9 aspect ratio in your movie player to compensate.

Because of this application, I am now able to browse and view iView programmes on my Eee PC, Apple eMac (PowerPC), play programmes on our TV (through our Xbox) instead of having to watch them on a computer screen, or watch programmes during car trips.

Installation

Method one: PPA for Ubuntu users

As of May 2010, the best method for installing Python-iView for Ubuntu users is to add the Python-iView PPA repository which is hosted on Launchpad.

To add the repository, run:

sudo add-apt-repository ppa:jeremy-visser/python-iview

Then, to install the package, reload your apt repositories (sudo apt-get update) and install the python-iview and rtmpdump packages (sudo apt-get install python-iview rtmpdump).

Method two: install manually for other operating systems or distros

You will need to install the following dependencies (apart from rtmpdump, all of these should be included in your distro’s package manager):

• Bazaar (package bzr in Debian and Ubuntu)
• Python 2.6 (preinstalled on most Linux distributions)
• BeautifulSoup (package python-beautifulsoup in Debian and Ubuntu)
• rtmpdump (download the source, and copy the rtmpdump executable to /usr/local/bin, or somewhere in your $PATH)

Then, run the following to download python-iview:

bzr branch https+urllib://jeremy.visser.name/bzr/python-iview/ python-iview

You can then cd python-iview launch either ./iview-cli for a command-line interface, or ./iview-gtk for a graphical interface. See the included README file for further instructions and usage examples.

In addition to their other unmetered services (including SourceForge), VoIP, and (relatively) gigantic download quotas, there is now absolutely nothing stopping us from switching to Internode from iiNet.