Making Sense of Mobile Streaming

Now that we’ve gotten streaming to computers down pat, I’ve set my sights on delivering a good experience for mobile users. Unfortunately, with the wide variety of mobile platforms out there, this is not an especially easy task. The Mac/PC/Linux issues are complicated enough, and it gets really tricky when the platform ecosystem has half a dozen major players (and a truckload of minor ones)

Since July or so, we’ve been using a preview version of the recently released Wowza V2 server software to deliver our video content to iPhone/iPod devices that support Apple’s new HTTP Streaming format. With minimal changes, Wowza V2 can also rebroadcast the same H.264/AAC stream over RTSP, which reaches a lot more devices. But this is where it gets complicated. BlackBerry has been supporting RTSP for some time, but it’s only recently that they’ve supported h.264/AAC media. According to their KB article on the subject, you can do H.264 on the following:

  • Bold 9000/9700
  • Tour 9630
  • Storm 9500/9520/9530/9550
  • Curve 8900/8520

Most HTC phones have a streaming media app that supports RTSP, but only recent versions seem support H.264. For example, my Mogul has the app, but I can only hear the audio. Brian‘s Touch Pro 2 gets both (and on the TP2’s WVGA screen, it looks amazing!).

Windows Media Player supports RTSP, but doesn’t come with an H.264 codec (even in Windows 7!!!! BOOO!!!!). I have yet to get the RTSP stream to work on Windows Media Player. The mobile player doesn’t support RTSP at all, just MMS and HTTP (but not the same HTTP as Apple! Grr!), and with the 9.5 generation of Windows Media Services (2008), MMS has gone away in favor of HTTP (which Microsoft calls Smooth Streaming, also not supported on WiMo).

The Palm Pre is supposedly able to do RTSP and H.264, but I’m waiting to hear back from one of our pre-wielding pastors to see if this is actually the case.

Thanks to Daryl Hunter at lifechurch.tv for letting me know that it works on his HTC Hero (Android 1.5). It seems that on Android you can’t manually enter an RTSP URL into the browser bar, but a web link or tinyurl redirect that goes to an RTSP URL does work.

Meanwhile, VLC player will play just about anything you throw at it, including the RTMP flash stream. Pity it’s not available in a mobile version.

So, as it stands now, in order to deliver a mobile experience to as many people as possible, I’m still going to need to run a separate Windows Media server for our Windows Mobile clients, But everyone else should be able to pull from the “iPhone” stream (which I’m probably going to need to rename), as long as the device supports H.264/AAC and RTSP.

 

Live Streaming On a Budget (Part 1) – Genesis

When our senior pastor started casting his vision of an Internet Campus which would revolve around a live (or nearly-live) stream of worship, it became pretty apparent that this was not going to scale well or cheaply. Over the course of the summer of 2008, we started exploring creative ways to do the impossible with nearly no money.

Read More

March Madness: The Network Plumber’s Perspective

Web video is clearly here to stay. Heck, I currently have 40% of my time dedicated to producing and delivering web video of our weekend worship services. I think this is tremendously cool stuff, and traditional one-way RF-based video delivery (a.k.a. TV) is pretty lame. My kids have no concept of a broadcast schedule. Their content world is one that is immersive, interactive, and on-demand.

We’re now coming up on that season that we network admins have begun to dread over the last few years: March Madness. With networks advertising live web video of every. single. game., those of us charged with the care and feeding of our WAN pipes are blanched in abject terror. We know that 95% of our staff is going to want to watch them while they work. It doesn’t take much math skill to figure out that multiplied by a couple hundred people, even viewing one event means that the remaining 3 people in the organization that don’t really give a hoot about hoops aren’t going to be able to get any work done and pick up the slack the rest of us are leaving.

When you do internet video on the scale of the NCAA tournament, or a news network during a major news event, you’re relying on the performance of your CDN. Naturally, you want to accurately count eyeballs so that the advertisers pay you appropriately. A lot of time and effort goes into engineering thse things, and it’s quite remarkable how well this works.

CNN’s approach using Octoshape is a creative one, that really pushes P2P technology into the mainstream of legitimacy. I was present at the creation nearly ten years ago [+] [++]when Gnutella was leaked to the world, and changed the rules of the multimedia distribution game, and recall thinking how interesting things were going to become. Out of the Gnutella proof-of-concept came LimeWire and others, and then BitTorrent figured out how to dial the concept to a global scale. Now the same idea is being integrated into mainstream CDNs with Octoshape and other “cloud” applications.

It seems to me that the CDN operators should be able to find a way to engineer their networks such that a corporate network admin (such as myself) could download a piece of software onto a spare piece of gear and run a node of the CDN, internal to the corporate network (or, for that matter, run it as a VMWare virtual appliance). This not only softens the blow to my WAN pipes, but also lightens the load on the public parts of the CDN. The only thing then going across the WAN connection is a single instance of each stream being requested by clients internal to the company. Then it simply phones home with the proper client count for advertiser tracking, and bingo, people can get work done, as well as watch their favourite team make a run at the Final Four.

…Or we network admins can simply block the CDN in their content filters and tell their users that we’re mean party poopers, depriving them of their hoops and depriving the webcasters of their revenue.