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">
        jwplayer("container").setup({
                height: 360,
                width: 480,
                image: "http://server.com/images/thumbnail.jpg",
                skin: "bekle.zip",
                modes: [
                        {
                        type: "flash",
                        src: "player.swf",
                        config: {
                                levels: [
                                        { bitrate: 250, file: "playlist-low", width: 320 },
                                        { bitrate: 500, file: "playlist-high", width: 480 }
                                        ],
                                streamer: "rtmp://streamer.com:1935/live",
                                provider: "rtmp"
                                }
                        },
                        {
                        type: "html5",
                        config: {
                                file: "http://streamer.com/live/ipad.smil/playlist.m3u8"
                                }
                        } ]
                }
        );
</script>

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.

Browser-Aware Player

One of the big challenges of streaming to the web is the sheer diversity of devices out there.

This past week, I pushed out some modifications to the player code on our live page that switches the player code based on what the user is connecting with. The genesis of this change was a problem with our change to JW Player Version 5 causing our PlayStation users to no longer be able to watch our video since JW v5 requires Flash 10 and Sony apparently doesn’t care about its customers. After a successful test with the Playstation, I extended the code to provide an HTML5 <VIDEO> tag for our iPhone users (allowing us to clear up some the clutter on the sidebar), as well as MMS and RTSP links around a graphic mimicking the Flash-based player in order to provide a consistent user experience for our Android/WebOS/BlackBerry/WinMo users.

EDIT: The main reason I’m not doing straight HTML5 with Flash fallback (a much more elegant solution) is that we’re sending out VP6 for our flash users and a lower-bandwidth h.264 stream for our mobile users. We’re not currently using h.264 for our flash users because of the poor quality of the h.264 encoder in Flash Media Live Encoder. Once we get a “real encoder“, we’ll send out a single set of h.264 streams and use HTML5 with fallback.

The code is here.