Microsoft Releases HTML5 Video Player Framework

The following tweet by Mike Downey caught my eye this morning. He announced that Microsoft have released Player Framework, which in their words is 'an open source video player framework for HTML5, Silverlight, Windows Phone and other application platforms'. Upon closer inspection it is the former Silverlight Media Framework, shifted towards HTML5.

It's interesting to note that this Player does not use Flash as a fallback technology, but enables developers instead to use Silverlight, or indeed choose from a variety of combinations such as HTML5 only (video tag), Silverlight only, fallback to HTML5 or fallback to Silverlight.
Whilst the player itself looks as one would expect, offering features such as mute, poster frame and full screen mode it also claims to add support for plugin models, advertising standards support, W3C timed text (TTML) for captions amongst other things.

What the demo also shows is the effort involved in providing a consistent cross platform experience when using the video tag. I'm not sure why, but when I tried the demo in FireFox on my Mac the 'Fallback to Silverlight' went straight to Silverlight and did not play the HTML5 content, but the HTML-only tab worked fine. Moreover since Silverlight does not seem to be compatible with the 64bit mode of my browser I saw no content at all, just a prompt to install Silverlight (which I am sure I already had installed - but maybe only a 32bit version?). I guess we can blame this on the beta status of the framework. But why not fall back to Flash anywhere? Is it really just because Flash-hating is a sport these days, or do companies simply not care about providing a good user experience? Is it too much to ask to detect the fact that I cannot run Silverlight and serve up a SWF instead?

Fullscreen mode is another sore point it seems. Whilst the framework claims to support fullscreen mode it really is just a full-browser mode - that's not full screen in my book. I also noticed some audio problems which surfaced in a delay when mute and unmute was selected.

All in all I congratulate Microsoft for putting in some effort and I am sure adding Flash fallback (let's be serious here: it makes a lot more sense than Silverlight fallback) would not be too difficult.
The plugin architecture of the framework also looks very useful, and some of the core features of the player are implemented in that way, with JavaScript providing the glue to it all.

You can check out the player demos here.

Dynamic Streaming Using F4M And Flash Media Playback Via CloudFront

Here is a quick heads up on an issue you may encounter when streaming video using Flash Media Playback and f4m files to provide dynamic streaming whereby the player will automatically pick the correct bitrate version depending on the user's connection speed.

In my case I wanted to stream my videos using Amazon's Cloudfront service. A typical RTMP URL will look something like this:

view plain
If you go ahead and create an f4m file using this you may end up with something like the following (presuming 3 bitrates at 500, 1000 and 1500 kbps):
view plain
1<?xml version="1.0" encoding="utf-8"?>
2<manifest xmlns="">
3<id>Dynamic Streaming</id>
7<media url="mp4:myvideo_500.mp4" bitrate="500" width="640" height="480" />
8<media url="mp4:myvideo_1000.mp4" bitrate="1000" width="640" height="480" />
9<media url="mp4:myvideo_1500.mp4" bitrate="1500" width="640" height="480" />
Unfortunately this file will not work when fed into Flash Media Playback. The reson (and fix) is quite simple and one some of us may remember from using the FLVPlayback component in Flash. It is a missing application instance name. In our case this is the default instance _definst_ that needs to be added to the baseURL. The correct f4m listing would therefore be as follows:
view plain
1<?xml version="1.0" encoding="utf-8"?>
2<manifest xmlns="">
3<id>Dynamic Streaming</id>
7<media url="mp4:myvideo_500.mp4" bitrate="500" width="640" height="480" />
8<media url="mp4:myvideo_1000.mp4" bitrate="1000" width="640" height="480" />
9<media url="mp4:myvideo_1500.mp4" bitrate="1500" width="640" height="480" />
I hope this helps someone. I was slightly confused by this as any one of my files would play fine using the FLVPlayback component without specifying the _definst_ in the video RTMP URL.

And one final gotcha: if you host your f4m files in an Amazon S3 bucket (but not your streaming bucket, you need to use a separate non-streaming bucket for non-video files) you may require your own crossdomain file inside it or the Adobe hosted Flash Media Playback SWF won't be able to load it.

A free tool to help you manage your S3 buckets (if you are on Windows - I run this tool in a VM) is CloudBerry Explorer. It's one of the better S3 related tools out there. Do you know an equally good one for OSX?

Google Removes H.264 Support From Chrome

It has only been a few minutes since the news of Google removing support for the H.264 video codec from Chrome in favour of WebM, a codec that Google open-sourced after their acquisition of On2, has been making the rounds. Is this significant? I guess it depends who you ask, but Chrome is certainly a browser that's quickly gaining traction, and rightly so.
I personally have seen very few videos in H.264 on the web that were *not* played back in Flash. Since Flash (as well as other plugins) will of course still be supported in Chrome there is always that option (with the notable exception of Apple's iDevices of course since none of those support Flash or indeed other browser plugins).

Adobe have already publicly committed to supporting WebM in Flash, and joined Google alongside many other companies on the WebM project. A notable exception on that list is of course Apple, an avid supporter of H.264. But it remains to be seen if Google's decision has any real implications in the short term. Things would look differently if YouTube was to stop encoding videos to H.264 and 'force' anyone wanting to play back new videos using a platform or browser that supports WebM.

Another party not to be pleased is undoubtedly MPEG-LA, the organisation responsible for setting and collecting licensing fees for H.264. Let's not forget: despite what Apple would like you to believe, H.264 is neither open nor free, and many companies including Adobe pay huge sums (millions I assume) to MPEG-LA in order to be able to add the H.264 decoder to Flash Player and other tools. And as John Dowdell confirmed, "when I've asked, I've heard 'millions' quoted for redistribution licensing as well." No small change then.

What does this mean for Flash? It could solidify its position as the safe bet for video playback on the web. There is little chance of Adobe removing support for H.264, and they are definitely adding WebM.

In the long run I'm not sure if Flash will remain the primary choice for video playback on the web. But as long as the rest of the landscape is in such a mess I cannot see it going away anytime soon. My prediction is that we will still see a lot of Flash based video being deployed in 10 years from now.

Learn All About Strobe And ActionScript-only Video Players

Mark your calendar for this coming Wednesday, 17th November 2010. The OSMF User Group is hosting an online event to which everyone is welcome; the title:
Building ActionScript-Only State-of-the-Art Video Players -- An In-Depth How-To Code Walkthrough (Using Codebase of Open Source Strobe Media Playback)

The session is an online code walk-through of the open source Strobe Media Playback video player codebase.

The code walk-through will be led by Andrian Cucu who is Adobe's Project Leader on the Flash and Strobe Media Playback video player project.

To join, just go to the following link at the meeting time to join the OSMF User Group's Connect room:

For further details and to RSVP see the following link:

Does HTML5 Video Playback Hog More CPU Than Flash?

This is not a trick question, but more of a pushback on the recent FUD that various people have been spreading. Quotes such as 'HTML5 video uses 10% CPU while Flash uses 100%' were both unprofessional and not backed up by any actual data. The short answer to the above question could in fact be yes - if I wanted to spin these results, but the more correct way of putting things would actually be: 'It depends'.

My co-author Jan has gone through some lengths to come up with the most thorough like-for-like comparison of HTML5 versus Flash video decoding requirements as far as CPU usage is concerned. His conclusions follow below, and I recommend you head over to his blog for the full story.

› Read Full Article

Ogg Theora versus H.264 Video Quality Shootout

My friend Jan has published some quality comparisons between the Ogg and H.264 video codec. For those who don't know, Ogg Theora is the video container format and codec favoured by Mozilla for playback of web video in HTML5 whereas H.264 is a widely popular codec - one may say the industry standard - that is used for all types of content from Flash (on sites that include YouTube and Hulu) to Blu-Ray and DVB broadcast television.

I can't say that I'm surprised about Jan's test results in which H.264 comes out on top. Ogg Theora is quite a dated codec which is based on Ons'2 VP3 specs, and which has become a free, open standard. Unfortunately the label of free software alone does not guarantee that Ogg Theora won't be vulnerable to yet unknown patents. For those reasons I would personally be very surprised if Ogg Theora sees any significant uptake in the future, even once HTML5 becomes more widely supported. Major players such as Apple and Nokia were amongst those who opposed the inclusion of this specific format as part of the proposed HTML5 specs, and it is highly doubtful that Mozilla alone has enough leverage to give this compression format a new lease of life.
Meanwhile both Safari and Chrome are focused on supporting H.264 which they consider to be a better choice for web video.

Check Jan's full article here and stay tuned for some more video codec specific tests in the coming weeks.

Flash Video versus Desktop Video - Apples and Oranges

Amongst all the noise that is currently being emitted after the jesusiPad announcement there are a also some high quality gems of content emerging, and Mike Melanson's piece on the different problems which the Flash Player solves when it comes to video delivery is one of them.

In particular Mike explains how a desktop video player and Flash Player differ. One obvious difference which surprisingly often gets overlooked, is that Flash Player is not just a video delivery medium but so much more than that. If you think back a few years there was barely any support for video in the Flash Player, and the only reason we hear so many complaints about its performance is due to the fact that so many people are using it these days. Flash has had an unprecedented growth curve when it comes to video delivery on the web, but it was a popular plugin way before then.
The issue Mike explains well in his article is that of users comparing apples to oranges a lot of the time: they compare a browser plugin to a desktop tool. In Mike's words, "a desktop player usually plays a linear media file from start to finish. Flash Player solves a different problem: It plays linear media files from start to finish while combining the video with a wide array of graphical and interactive elements (buttons, bitmaps, vector graphics, filters), as well as providing network, webcam, and microphone facilities, all programmable via a full-featured scripting language, and all easily accessible via a web browser using a plugin that most of the browsing population already has installed."

Mike's article in full can be found here. Please bookmark it and send to everyone who asks you next time: "Can you explain why a video player like VLC can play the same flv file with less CPU usage than the Flash Player?".

And the main takeaway: "The Flash Player works to solve the problem of making video accessible via the web browsing environment. In contrast, a desktop media player plays a file using a dedicated, single-purpose application."

Dynamic Bitrate Streaming Demo

I'm finally finding a bit of time (at 10pm) to upload a little video demo that had been sitting on my hard drive for a couple of months. The premise was that I wanted to have a play with the new dynamic bitrate streaming feature in Flash Media Server so I grabbed a trailer from Apple's website, fired up Flash Media Encoder and encoded the District 9 HD clip into 3 bitrates to .f4v format: 400kbps (low bitrate), 800kbps (medium bitrate) and 1.5mbits (high bitrate).
Video quality was not my primary goal here (as you can probably see from the footage), instead I just wanted to see how hard or easy it is to get something like this up and running. Bottom line: not too difficult at all.
I've got a copy of FMS 3.5, a dedicated server (UK based) with a decent bandwidth allowance so I figured why not release this into a the wild?
One thing that you should pay attention to is the actual bitrate switching. If your connection speed is very stable then you may right-click the player and choose to manual switching - let me know if you can tell when the delivered bitrate changes, I bet you can't. And that's the beauty of this technology in a nutshell: seamless switching between bitrates. Pretty neat. Note you can also click the little HD icon/bandwidth bar to bring up a console with stats about the video and playback.

I'm sure some of you will ask for sources, but to be honest there aren't really any to share. I just grabbed the Open Video Player and configured it completely via flashvars, so I have not even got a FLA I could show you. As for the video settings I used - sorry but I can't honestly remember. All I recall is that I downsized the clip a bit so the resolution is not the same as in the original source footage, and no other fancy settings were used. As I said I simply encoded using the Flash Media Encoder.
Enjoy, and let me know what you think.

Accessing the NetConnection Object in FLVPlayback

There are situations where it is necessary to call a server side method on FMS. Some CDNs, for example Limelight, used to or maybe still do require you to call the FCSubscribe method in order to request a live stream. This send a signals to the Edge server to pull the live stream from the Origin server if it is not already being delivered to that Edge. While this delivery method and stream setup routine is being phased out across most CDNs I thought it may be useful to post a (slightly hackish) workaround to make this setup work with the FLVPlayback component.
The problem with the FLVPlayback component is that there is no obvious, simple way to obtain a reference to the NetConnection Object it uses under the hood. Sure, the ncMgr.getNetConnection let's you grab it but only once the connection is established, and while you can implement a custom NCManager class, this is not trivial and after all a NetConnection is being maintained already by the component, so why reinvent the wheel?

The following code is clearly not something I am proud of, but it worked at the time when I needed it. It was used to get a live stream working with the FLVPlayback component streaming from Limelight about a year or two ago.

view plain
1// listen to player events and kill manual connection once we're streaming
2    player.addEventListener("playing", playListener);
3    player.addEventListener("stateChange", stateListener);
4    player.addEventListener("ready", readyListener);
6/* this is the hack: check once every frame if the NC has been defined inside the FLVPlayback component */    
7    this.onEnterFrame = function()
8    {
9        if (player.ncMgr.getNetConnection() != undefined)
10        {
11            this.onEnterFrame = null;
12            delete this.onEnterFrame;
13            trace("got NC");
14            //subscribe(streamName);
15        }
16    }
18    var nc:NetConnection;
19    var serverName:String = "";
20    var appName:String = "account_name/_definst_";
21    var streamName:String = "live";
23    var source_Str = "rtmp://" + serverName + "/" + appName + "/" + streamName;
25    // start up by setting the contentPath (now called source in newer versions of the component)
27player.contentPath = source_Str;    
29    function subscribe(name:String)
30    {
31        nc = player.ncMgr.getNetConnection();
33        nc.onFCSubscribe = function(info:Object)
34        {
35            trace("onFCSubscribe: " + info.code);
36            clearInterval(int_id);
38            if (info.code == "NetStream.Play.StreamNotFound")
39            {
40                // handle error, retry after a few secs or similar
41            }
42            else if (info.code == "NetStream.Play.Start")
43            {
44                // we're successfully subscribed
45            }
46            else
47            {
48                // handle error
49            }
50        };
53// not used right now
55nc.onFCUnsubscribe = function(info:Object)
56        {
57        }
59        trace("subscribing to " + name);
61    }
63    // can be used to unsubscribe from stream
65function unsubscribe(name:String)
66    {
68    }

Hopefully this is helpful to someone.

Deep Thoughts on Silverlight

Jan just posted a great article about Silverlight, Flash and RIAs in general. As expected, Jan approaches the topic from a video angle, but comes to some of the same conclusions as many of us here in the Flash camp: "If Microsoft dropped Silverlight tomorrow, most web site owners and 'Netizens' wouldn't even notice, or care if they did."

And of course I'd like to give Jan a hug for quotes such as "Flash caught on because it provided design functionality that HTML couldn't match and solved problems that no other technology could. It succeeded because website designers, developers and owners wanted it, not because Adobe needed it."

Very true. And that also means that Adobe gave those designers, developers and content owners the right tools for the job at the right time. Let's not underestimate the foresight Adobe had back in 2000 or so - long before anyone ever heard of Youtube and the like - when the foundations were laid to make Flash the de facto video standard on the web. While I doubt they envisaged quite this level of success they were certainly aiming for it. Has Adobe been able to leverage the success of Flash video and turn it into a money spinner for themselves? Not really. But have they managed to secure the future of the Flash platform for some time to come? Definitely.

It's onwards and upwards from here for Flash video. Adobe is undoubtedly busy cooking new and clever features in the labs, and anyone who has seen or watched the RTMFP sneak peaks at MAX knows that this technology could be another game changer. I can't wait to see more. There are many good ideas still to be had.

PS: I recommend you read Jan's full article, including the first part which focuses more on UGC and H.264.

More Entries