Everyone’s talking about IP TV and how it’s going to revolutionize things. We’ll be able to get our TV anywhere, any way, but the reality has fallen short of the promise. Your ISP may be beaming Digital channels down to you over IP, but the experience is largely unique to your ISP. Your cable box is not a TV Content browser, no matter how much it tries to be. Heck, you can’t even take your Time Warner Cable box and easily connect it to a Comcast user’s home. The spirit of the IP in IPTV is sorely missing.
That’s why I’m working on a better way–and I need your help.
There are several standards regarding IPTV (and they are used), but while they focus on delivering the content, they do not focus on the programming. If you’re looking at the web to solve your problem, don’t look there either. Every single news or content producer has their own site with their own way of accessing it. You need accounts, you need a pretty hefty browser, and you need to wade through a different interface each and every time.
There is no way to channel surf on the web.
What about RSS?
RSS is great! I love it, but it drastically changes consumption of media, albeit in a very Web way. TiVO’s and DVR’s help bridge this gap on the classic TV side, but what about programming? Sometimes I don’t want to pick what to watch. Sometimes I just want to flip through channels and see what’s on. RSS does not replace programming. (I’d also like to take this moment to give a big shout-out to Miro, which is an amazing application for automagically downloading and managing video RSS feeds.) We need something more.
A New Way to Surf
What we need is a format for serving up programming that goes beyond a fixed stream. We need a way of mixing up content, and the web. We also need a better way of consuming it all. Without giving it an official name, I’m going to call this protocol LP. Imagine if you could pull down a link to your favorite channel’s programming and view content live. It’s not a stream, it’s a url your LP player goes to and it contains all the information you need to find out what’s playing now on your favorite channel. Heck, why stop with now? Maybe it’s all pre-recorded and you can skip to what’s playing later? Maybe, you want to see what was on before? Who needs a DVR? The content should stay available and you should be able to consume it. What I’m talking about is a REST API for navigating video and audio content.
A Trudge Through the Mud
I first started writing this post four months ago and I kept putting it off. Then I wrote some more and put it off a few more months. I had all these ideas in my head and I wanted to get them all out in one go. I wanted to have a working prototype of an LP Server and Player, of the “LPXML” format, and have all the whizz-bang features I wanted to put into it. The fact of the matter is I’m busy and it will take me forever to settle my ideas if I don’t just start and get something out there. So I’m going to start with just the basics of what I think this “informal” standard should look like.
And I’m definitely looking for feedback.
What I’m proposing is that an LP player take a link to a website (e.g. www.spaceislimited.org/lplayer/) and this will be the root of the lplayer REST interface for my site (the link is hypothetical btw). The Lplayer application (this could even be Miro if this catches on) would then know the following structure for the REST inteface.
lplayer/now/ – This verb will respond with a page that will contain the URL of the content that is currently now playing. For example, the Lplayer goes to lplayer/now/ and get this response:
<code>
<a href=”http://spaceislimited.org/videos/awesomevid1.lpxml” />
That’s it. Nothing else. Maybe eventually we’ll specify an XML doctype and wrap it in something like:
<?xml version=”1.0″ encoding=”utf-8″?>
<lp version=”0.1″ xmlns:lpxml=”http://www.lpxml.org/lpxml.dtd”>
<program>http://spaceislimited.org/videos/awesomevid1.lpxml</program>
<elapsed>20</elapsed>
</lp>
</code>
The player would then follow that link to get the content and some meta data about the content. It would also use the elapsed value to sync up with how far into the program everyone is. Of course, if it’s a live stream, the elapsed value may not be necessary. The program link might look something like this:
<code>
<?xml version=”1.0″ encoding=”utf-8″?>
<lp version=”0.1″ xmlns:lpxml=”http://www.lpxml.org/lpxml.dtd”>
<content size=”small” codec=”quicktime” bitrate=”100k”>http://spaceislimited.org/videos/awesomevid1_lowres.mov<content/>
<content size=”medium” codec=”quicktime” bitrate=”200k”>http://spaceislimited.org/videos/awesomevid1_mediumres.mov<content/>
<content size=”high” codec=”quicktime” bitrate=”300k”>http://spaceislimited.org/videos/awesomevid1_highres.move<content/>
<language>en-us</language>
<title>Awesome Vid – 1</title>
<description>This is part one of an awesome video I made and you should check it out.</description>
</lp>
</code>
Depending on the player, it can choose one of three files to stream, each with a different bitrate. For example, if you had an LPlayer on your iPhone, maybe it would choose the 100k stream, while your home computer might opt for the 300k stream. Also, the rest of the meta-data is standard stuff which could be used within the application.
So what happens when the video is done? Simple, the player would then go fetch the /lplayer/now/ link again and get what’s playing now! If it still sees the same entry, it might wait a few seconds and try again (maybe your lp server site is so awesome it’s having trouble responding). Or the application could try /lplayer/next/ and get what’s playing next. That way, your iPhone can start buffering what’s next a few seconds before!
A Call to Arms
I’m publishing this as an informal standard and I’d love to see your comments behind this. More than that, I’d love to see people who are willing to work on this with me on setting up a community around this and implementing a free server and player for the “LP” standard. For this standard to work, it needs to be open, simple, and platform and codec agnostic. I haven’t said anything about needing to use the QuickTime codec or having to choose a standard bitrate. This is about discovery and enabling the player to make the right choice. Attached is the standard–plain and simple for now. In the coming weeks I’m going to work on getting a site (lpxml.org), wiki, forum, and mailing list (lpxml [at] googlegroups [dot] com) setup so we as a community can work on this. I hope you’ll join me.
oowssfz2kmqil25y