For years I tried on and off to get a complex MythTV setup up and running. I eventually came to the realization that a broadcast-based system wasn’t ideal as broadcast was slowly dying off, and I can continue to use TiVo through its demise. Currently I’ve got XBMC (mostly) running on a couple of machines and partially working on 2 old XBOX machines (thanks to eBay for really cheap hardware), and I’m fairly happy so far. But to look down the road, where do I want to go from here? Boxee is a possibility, as are Roku/Popcorn/etc, but they aren’t that much better than XBMC, and they all are less open. So what then?

If you watch the current war between Apple and Adobe over flash or the emerging video format standard wars between Mozilla/Ogg and the H.264 consortium you can see at least one clear trend – all browsers will be natively supporting video, and doing it really well. Everyone is promising video processor accelerated HD playback, and users who are weary of Flash’s tendency to max out a processor will hold the browser makers and Adobe to their word.

So, with browsers being able to do native video, the next generation should be a thin client solution. HTML5 and CSS3 are powerful enough to give you XBMC-like control and transitions. With the the codec built into the browser and already optimized to the hilt, the idea of using any other external or embedded player is outmoded. The only browser hole I see on the client side is remote control support, but even that may be solved as I want to use an Adroid app on my phone over WiFi, at which point its a simple JSON service.

Even in the most basic setup with all local content, there still needs to be some server component as the browser isn’t reading directories directly. Something needs to feed the list to the client, and presumably host the app. More complex setups would include meta data storage (e.g., number of times a video was played, where the user left off last time, rating) up through complex tasks like on-the-fly transcoding.

So where does this “server side” reside, in the cloud or local to your network? The answer is that it is a distributed network of services whereas one server (either local or in the cloud) is the client’s master source. When the client requests something from a secondary source, the master acts as a unifying go-between, with the exception of the streaming itself. The master source is where the user browses to get the HTML and services, it maintains a database of the user’s configuration and preferences. It doesn’t necessarily store the full catalog, relying on data from the other source servers.

When a client requests a resource the server service that owns the content is called upon to serve it up. This may simply be pointing to the file, or it could be going through a translation or transcoding process. The master source will store meta information as described above, such as when it was last viewed.

What makes this one evil? Its not especially sinister. It does cut into Boxee and others’ business by providing a modern architecture with lower development cost. The revenue stream is the same – partnerships to provide more prominent content placement as well as traditional ad-based revenue. It is sufficiently simple that it will be cloned and open sourced, so the strength of the partnerships is key to maintaining paying customers.

In the end the architecture is quite a bit like my old Myth setup, which also had a single master server, subordinate servers, NAS resources for content, and slightly less dumb clients. And just like Myth’s failure to catch on due to its complexity in the face of sealed consumer electronic device alternatives, my vision also has enough complexity to confuse or scare off most users. The more things change the more they stay the same.