Browser-aware player code, revisited

I posted a while back about selecting video players based on browsers… It was an ugly javascript hack, and since then LongTail has updated their excellent JWPlayer to support multiple methods. In order to create an embed that worked best for supporting both HTML5 and Flash players, I had to dig through the documentation a little bit, and combine a couple of different sections.

Here’s how to embed JWPlayer 5.7 to try flash first, with multiple bitrates, and then attempt HTML5 if Flash is not supported. This particular scenario is for iOS support.

<script type="text/javascript" src="jwplayer.js"></script>

<div id="container">Loading the player ...</div>

<script type="text/javascript">
                height: 360,
                width: 480,
                image: "",
                skin: "",
                modes: [
                        type: "flash",
                        src: "player.swf",
                        config: {
                                levels: [
                                        { bitrate: 250, file: "playlist-low", width: 320 },
                                        { bitrate: 500, file: "playlist-high", width: 480 }
                                streamer: "rtmp://",
                                provider: "rtmp"
                        type: "html5",
                        config: {
                                file: ""
                        } ]

This still doesn’t support RTSP and other HTML5  fallbacks due to limitations in JWPlayer, so if you’re on a BlackBerry, you’ll still need to switch the player. The order that the “type” statements appear in the javascript determines the order in which they’ll be tried. Generally, you’ll want to try Flash first, otherwise browsers that support HTML5 but not Apple’s HTTP Live Streaming (which is pretty much all of them), will default to the HTML5 player, but be unable to get the stream. You can, however, provide multiple video sources with different codecs (for on-demand content) to support the different flavors of browsers, though.

Footnote on Automating EC2

Yesterday was the first live test of our EC2 automation, and it worked beautifully. One thing I discovered was that when the Wowza servers shut down, Flash Media Encoder simply attempts to reconnect to the server until it succeeds. This is very helpful, since I can just leave the VT5 system on a loop or on the program feed, and as soon as the servers are ready, they’ll start broadcasting.

That way, if something happens and nobody shows up, we’ll at least have something going on the stream.

If you’re using an unattended encoder, you can also take advantage of this (and even schedule start/stop of the encoder software, but it doesn’t have to be timed exactly to the server start/stop.

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