The coming paradigm shift in TV broadcasting

The coming paradigm shift in TV broadcasting
The coming paradigm shift in TV broadcasting

This article comments on Apple’s latest move to offer video content through their iTunes and how this is a logical and inevitable move with some far ranging effects.

In this blog post I abstract from this and apply it to the whole telecommunications, media and IT industry. Some things are about to change in this economically important sector.

It’s understandable they put up a fight. The telecommunications sector is built on the notion that exchanging information (in any form) costs money. The media industry is built on the notion that media needs to be distributed (physically) and that they can charge dollars for that. And finally the IT industry is used to steady income from license fees from software. All these industries may lose a lot of revenue if the rules are changed.

And that’s what’s going on. Apple just changed the rules for the Media industry. This will have a snowball effect. Right now if you want to watch something (movie, the news, tv series, documentary) you need to turn to one of the industry controlled and closely guarded media: cinema, a tv channel, a dvd, etc. Each of these things is a source of revenue to the industry and you pay directly or indirectly for it in all sorts of ways. There’s nothing against that in principle they offer access to scarce resources and people pay a market price for access.

Their problem is that Apple just made these resources a lot less scarce. Distribution through the internet of content is cheap and will become even cheaper. Technology will gradually erode the cost to close to 0$. There’s plenty of bandwidth available and an increasing amount of people has what I call a critical amount of bandwith: enough bandwidth to make streaming high definition audio and video feasible & desirable.

Apple is tapping into this by letting their users access content over the internet through their iTunes store and by providing the necessary hardware and software to them. That’s a small change and not at all revolutionary. But it will teach people an important lesson: hey I can watch desperate housewives (one of the offerings used to commercialize the new itunes ability) whenever I want, wherever I want and I don’t need to buy the dvd, I don’t need to turn on the tv on a specific time and I don’t need to watch the commercial blocks. The next steps are obvious and imminent: why store the desperate housewives episode on an ipod when you can just stream it? Mobile networks will soon mature enough to reach the same critical bandwidth as home users are currently enjoying on their home networks.

That means that anytime, anywhere you can start streaming anything to your mobile phone, your pda, your ipod, your tv that anyone bothers to put online. Inevitably this will replace all existing forms of content distributions. Why tune to a channel to view some program when you can just start streaming the program whenever you want, skip to any part you want and pause it whenever you want, etc?

Apple just gave the industry a little reality check, just like they did when they kick started online music sales a few years ago: if the industry doesn’t move, somebody else will. Over the next few months, one after the other media company will either join apple or similar iniatives from e.g. microsoft. Once this happens the pressure will be on and the market will do its work. Better content leads to more online revenue, at the cost of traditional revenue. The huge gap between cost of content production and content distribution and the market price (which is obscene) will start to come under pressure as well. At some point in the near future the market model will change from paid downloads to paid streams (subscription, per view, etc).

This will put an end to tv networks as we know them. They are content distributers and we don’t need them anymore.

The same is going on in the telecommunications sector where revenue used to come from telephony and related services. IP telephony has eliminated the need for paid telephone services since it works just fine over a modest internet connection. If you have umts phone, it is technically possible to use the internet for IP telephony so why exactly are we paying 30 cents per minute for a local phone call? Some mobile networks already offer fixed price bandwidth (expensive though). The operators on these networks get their revenue from a number of services, all of which with the exception of the network connection are technically possible with already available software packages that use the connection. People think it’s normal to pay 25 cent for the delivery of a 160 character message to a cell phone (SMS). If those two cellphones are umts phones and run msn, icq, aim, jabber or any of the other IM network clients you can send unlimited messages to anyone freely. Surprisingly few people have figured this out but they will. These changes are already happening and will kill much of the telecom industry as we know it. A mobile phone is nothing else than a general purpose computer with a umts modem or similar wireless connection and some general purpose software. The form factor is irrelevant.

Which brings us to the software industry because nothing of the above requires software with a pricetag greater than 0$. All of the services mentioned above can be implemented using existing, open source software. In fact oss developers have already done most of the work and created OSS media centers, video & audio codecs, communication software, real time operating systems and any other kind of software component you could possibly need to implement any of the services mentioned in this document. It’s just a matter of putting together the components.

So what remains is bandwidth, hardware and intellectual property. Any revenue not coming directly from these, will vaporize in the next few decades. The remaining revenue will still be sizable but probably less than the industry is used today. 50$ for a dvd now is considered normal today. I’d be surprised and disappointed if I was unable to watch star wars III on my mobile phone anywhere, anytime for over 5$ in about ten years. And no way am I going to watch that shit ten times.

My impression is that the whole proces will be slow thanks to the industry resisting any form of progress. It will take some outsiders, like Apple, to change the rules gradually. These outsiders exist and are already changing the rules.

jaxb

Here’s a simple use case which I imagine happens a lot:

You’re writing a Java application. It requires storing data in xml and retrieving this data from xml. It used to work like this:

  • Write some prototype xml that more or less has the information you need. At this point you expect things to evolve.
  • Parse the thing into a DOM or write a sax handler in Java
  • Write some code to extract data from the xml document and store it in memory as java beans
  • Write some code to turn the beans back into xml
  • Tune parsing code and xml as required while you develop the rest of the application

The above process is tedious. An important reason for this is that neither SAX nor DOM are very javaish. DOM was designed to work well with limited languages such as javascript. Hence everything is a Node. That sort of sucks if you have a language that supports inheritance and interfaces. Instead of using java language features you have to write code to check what kind of node you are dealing with and use tedious calls to extract information. In short, the DOM api sucks big time from an OO perspective.

SAX is worse, it is a very low level API that requires you to write event handlers to get data out of it. The only nice thing about it is that works ‘on the fly’, so you can prevent buffering the entire thing in memory.

Neither are very nice to work with in the above scenario. In most cases all I want to do is something like this:

Document foo = Document.parse("foo.xml", FooInterface.class);
FooInterface fooBean = (FooInterface)foo.getBean();
Bar barBean = (Bar)fooBean.getBar();
barBean.setFooBar("foobar!");
Document.writeXml("foo.xml", fooBean);

In short I want to unserialize some xml, do stuff with it and then serialize it back and not spend to much time thinking about how that should be implemented. There are of course some problems with this:

  • there are multiple possible xml structures to serialize to, which one is correct
  • the interfaces may not fully define the constraints this xml should match
  • there might be other, non java applications that need to do stuff with the xml

Here’s how sun expects people to solve the above problem (using JAXB):

  • Write an xml schema that describes your xml format
  • Compile this schema into java code with interfaces & implementations of beans that match this schema & some parsing and unparsing code
  • Write code that depends on this generated code

This solution has a number of problems:

  • You need to write an xml schema before you write any code. That sort of doesn’t work when you only have a rough idea of what should be in the xml
  • The code that you write to access the generated beans has a necessary level of indirection and is therefore ugly.
  • Any time you edit the schema and regenerate your bean you potentially break this ugly code.
  • XML schema is very complicated, you are likely to iterate multiple times to get it right, even if the xml format does not evolve.
  • The reference implementation of JAXB comes with strings attached. It’s a typical SUN thing bundled with piles of documentation, a shitty installer, a shitty license, lots of dependencies on stuff you don’t really need. There’s not much else. Apache JAXME is a project that intends to fix these issues but at 0.5 it is somewhat a risk to use in a project.

In short, like so many xml based tools, JAXB is an overarchitected solution that doesn’t actually have much advantages over hand parsed and unparsed stuff for the simple use cases that are so common. I’ve written plenty of xml parser code based on the DOM api and I’ve decided to keep doing that. In fact, in the time I used to figure out the above I could have written it for what I am currently building.