Lately I’ve been writing more often about my work on feng and the lscube project ; the idea behind lscube is to get a well-working and well-scaling entirely free streaming software stack, both server-side (feng) and client-side (libnemesi), with the ability to stream live content (with flux). The protocol used by this stack is the Real Time Streaming Protocol, currently version 1, as designed by the RFC2326. RTSP, originated from RealNework, is just the control protocol, and uses out of band connections for sending the data, using, in our case, the RTP protocol (or it can use multiplexed connection, like interleaved RTSP or SCTP). The whole protocol description is quite tedious and is not what I’m interested in writing about right now.

What I think might be worth explaining is why we still care about RTSP, given that the reality of audio/video streaming lately seems to focus on the much more generic HTTP protocol (calling it Hyper Text Transfer Protocol was probably underestimating its actual use, I guess). Indeed, even cherokee implemented support for a/v streaming and while Alvaro shows how this can be used to implement the <video> tag, we also know that the video tag is not going to be the future at least not for the “big” stremaing sites. Indeed most streaming sites will try their best to avoid external players to access their content. But RTSP is, after all, being implemented by a very wide range of companies, including two open-source server software projects (Helix DNA Server by RealNetworks and Darwin Streaming Server by Apple), and both Apple and Microsoft with their own multimedia stacks.

The idea is not to use RTSP for small video streaming, which can, after all, very well be cached, but rather to have longer-playing content be streamed, with a few different advantages over the HTTP method. First of all, HTTP isn’t really practical for live streaming, either unicast or multicast doesn’t really matter here, it’s much easier to do with RTSP than HTTP. Also, RTSP allows for precise seeking and pausing, which HTTP does not allow, without doing lots of tricks and hacks at least. And then there is multicast, the magic keyword that I’ve heard spoken many times since I had my first internet connection. Indeed, my ISP used to have some experimental multicast-based stream for 56k dial-up and 256kbit ADSL; nowadays they don’t provide that feature any longer (I know nobody who was ever able to get it to work anyway) but I guess they did use the data they researched at the time to implement their IPTV system on ADSL2.

I have one situation clear in mind where mutlicast streaming, together with precise seeking, would be very helpful. At my high school we had a “English multimedia laboratory”, which basically was a classroom with fourteen crusty PCs wired up together; half the time we would use them as normal computers to browse the net for whatever reason (usually because neither the teacher nor the lab assistant wanted to do anything during the day), the other half they would be switched to just repeat the same video signal to all the monitors (which were, obviously for the time, CRTs; on the other hand the way the stuff was wired up, in either mode the monitors further at the back had very bad signal). Doing the same thing, all digital, with a simple Gigabit Ethernet connection, would probably have given quite better results (on the other hand, one could argue that having a single big TV would have saved the hassle).

Now, while all these things can probably be forced down HTTP’s throat with webapps, services, protocol extensions and whatever, having a dedicated protocol, like RTSP, that handles them, is probably quite an improvement; I’m certainly looking forwards for the day when my set top box in my bedroom (the AppleTV right now), would be able to stream my anime down the Ethernet connection with RTSP, so that I could seek without having to wait for the buffer to catch up, and easily skip to the middle of an episode without having to wait for all of it to be downloaded.

So basically, yeah RTSP is a bit more niche than HTTP right now but I don’t see it as dead yet at all; it’s actually technologically pretty cool, just underutilized.