We’ll compare the following aspects of each browser’s implementation of the video element as compared to a Flash based video player and Native video players (Native players being Windows Media Player on Windows and Quick time/QTX on MAC).
1. Playback Performance
2. Feature Capability
3. Feature Performance
Playback Performance
This is the ability of the browser’s built in player to playback high quality video at the frame rate the video is encoded at (that is extremely smooth without stutter, jerks or sticky frames). Videos encoded with bit rates of between 4000kbps – 7000kbps at dimensions of 720p and 1080p are considered high quality for the purposes of these test.
We know that Flash based video players are
unable to come close to the playback performance of native players. On Windows, Flash player has direct access to hardware acceleration (
hardware acceleration is explained in simple terms later in the article). On a MAC, Flash player 10.1.82.76 in combination with OS X v10.4 and above can use hardware acceleration. So most MAC users are unable to watch high quality videos when played back using Flash based video players.
1. MacBooks shipped after January 21st, 2009
2. Mac Minis shipped after March 3rd, 2009
3. MacBook Pros shipped after October 14th, 2008
4. iMacs which shipped after the first quarter of 2009
This doesn’t mean that all of the above hardware can playback high quality HD video, but only that they have a hardware decoder for H.264 when using Flash player and not other players.
The MAC user's plight
Currently, however, 480p video, running on a 1.8GHz Mac mini, uses 34 percent of the CPU in Mac OS X and just 16 percent in Windows (running in BootCamp on same hardware). Flash 10.1 is expected to cut CPU consumption in half. So Html 5 video is truly a benefit for MAC users, at least those who don't have newer hardware and/or OS
Video Codecs
Since the Html 5 specification does not specify a specific video codec, browser makers are free to support one or more of the common codecs. For the purposes of this test we have used the following codecs:
1. H.264
Further, there are multiple versions and these versions differ in dimensions and quality so as to support visitors with varying bandwidth and computer hardware capabilities. The following versions have been used for this test
1. 480p@2600kbps
2. 720p@4000kbps
3. 1080p@7000kbps
So there are 6 actual video files that have been encoded for the purposes of these tests. 3 encoded using the H.264 codec and 3 encoded using the
WebM codec.
Html 5 Video Full Screen
At the time of this writing, only Safari provides a built-in way to go to full screen. However as per the Html 5 video element specification, browser vendors should not provide a programmatic way to go to full screen. Only an actual user gesture, such as a physical mouse click can activate full screen. As a result this is what happens:
1. Only the default controls could provide a way to go to full screen or browser vendors could provide a context menu (right click over the video and choose full screen). At this time only safari provides a full screen button on its default skin.
2. Most websites will have their own skin and will want to programmatically control the built-in video players. So this poses a problem because we’ll then need programmatic access to go to full screen.
Safari goes against the spec in this case (thank goodness) and provides a programmatic way to switch the player into full screen and we use this in our player's implementation. It's likely that other browser vendors will follow.
In other browsers we’ve implemented our own full screen feature in our player that works in every browser regardless of whether the browser provides one or not since we can’t access that feature anyway. And we want viewers to have a uniform experience when using our player no matter what browser they use.
Browser Full screen Mode
All browsers except Safari provide a way to set the browser in full screen mode using the F11 key (for the purposes of video Safari does not need this option). Note that this just puts the browser in full screen mode and has nothing to do with video. So the best user experience (non-Safari users) for full screen mode at the time is to hit the F11 key (to put the browser in full screen mode) and then to get the video to go to full screen so it fills the entire screen of you monitor and not just the browser view port.
Single Codebase
It was imperative that we can use a single codebase for the html 5 video player across all browsers, without the need to do any browser sniffing and or conditional code paths for different browsers. However, since the video element does not function or behave the same across browsers (either due to their interpretation of the html 5 video element spec or limited support at this time), we have accounted for these nuances in the implementation of the video player to the extent possible.
Html 5 Video Comparison Results
For those of you only interested in knowing the results, I’ve tabulated them here.
All tests were performed on a 4 core 2.66GHz, 64bit hardware with 4GB RAM and Window 7.
IE 9 and Safari 5 are the winners. Both these browsers do a fantastic job of playing back high quality HD video, really impressive indeed.
| Playback Performance |
IE 9
PP4 |
Firefox 4
Beta 4 |
Chrome
6.0.4 |
Safari
5.0.1 |
Opera
10.61 |
| 480p |
6% |
10% |
12% |
16% |
21% |
| 720p |
9% |
19% |
18% |
25% |
42% |
| 1080p |
17% |
25% |
32% |
40% |
56% |
| The numbers within the cells indicate CPU utilization percentage |
|
Excellent - absolutely smooth playback |
|
Mediocre - skips frames and/or sticks on relatively tough to tough scenes |
|
Poor - Unwatchable |
Notes
As you can see from the results above CPU
utilization is not an indication of how well a player can perform. From the
looks of it however, it would seem that vendors who have experience with video
players, know what the heck they’re doing.
Playing the 1080p (H.264) version using Windows
Media Player on the same computer utilized 12% CPU as against 17% compared to
IE 9.
The 1080p version using a Flash based video player
was completely unwatchable and the CPU utilization was at 70%. For the 720p
version, I'd give the Flash based player “good” and not excellent and the CPU utilization
was at 60%. For the 480p version I’d give it an Excellent and the CPU
utilization was 40%.
Chrome is the Winner supporting both the H.264 codec as well as the WebM codec. In the near future, IE 9 and Chrome will tie since IE 9 will support WebM as well. No one knows if Safari will ever support
WebM and Firefox and Opera have made it very clear that they will not support H.264.
| Code Support |
IE 9
PP4 |
Firefox 4
Beta 4 |
Chrome
6.0.4 |
Safari
5.0.1 |
Opera
10.61 |
| H.264 |
|
|
|
|
|
| WebM |
|
|
|
|
|
| Will Support H.264 in Future |
|
|
|
|
|
| Will Support WebM in Future |
|
|
|
|
|
Notes
This one aspect (codec support) alone has the potential of delaying the adoption of Html 5 by every online video hosting website. Because what this means is that in order to support visitors using any of the primary browsers, they would have to encode every video using H.264 as well as WebM.
H.264 is by far a superior codec. WebM is not too bad but what WebM lacks is hardware decoders on mobile platforms or no support at all (iPhone, iPad). So in order to support desktop and mobile platforms, video hosts will have to encode videos using H.264 as well as WebM. This means double the compute power, double the time and double the storage space.
Chrome and Safari are the winners here.
But wait! Take a look at the Feature Performance chart.
The features listed here are features that are
typically required by a video player and are implementable using a Flash based
video player. These are considered essential features.
| Feature Capability |
IE 9
PP4 |
Firefox 4
Beta 4 |
Chrome
6.0.4 |
Safari
5.0.1 |
Opera
10.61 |
| Skip ahead |
|
|
|
|
|
| Change version while playing |
|
|
|
|
|
| Toggle Full screen while playing |
|
|
|
|
|
| Full screen and then play |
|
|
|
|
|
| Ability to show download progress |
|
|
|
|
|
|
Works As Expected |
|
Flaky - Works sometimes |
|
Does not work |
Notes
Keep in mind that IE 9 is a platform preview and
not yet a beta, so one would expect some glitches. However, one could say - "too
little too late".
Firefox and Opera are lagging behind the other
browsers in this department. Opera is of course worse since two of the
essential features are flaky at best.
Even though it looks like Safari ties with Chrome because it is capable of these features, sadly the performance of these features is extremely slow. Take a look at the Feature Performance chart below
It was found that the different players have
varying response times to the various features we tested against and so we
decided to compare their responsiveness to certain actions.
IE, Firefox and Chrome tie this one. We’ve included
IE 9 as one of the winners here because its responsiveness to other features is
excellent and in fact it is the fastest in responsiveness. Since the full screen
feature does not work we couldn’t really test the responsiveness of this
feature.
| Feature Performance |
IE 9
PP4 |
Firefox 4
Beta 4 |
Chrome
6.0.4 |
Safari
5.0.1 |
Opera
10.61 |
| First Time Play |
|
|
|
|
|
| Skip ahead |
|
|
|
|
|
| Change version while playing |
|
|
|
|
|
| Toggle Full screen while playing |
|
|
|
|
|
| Full screen and then play |
|
|
|
|
|
|
Almost instant response |
|
Flaky - When it works, almost instant response |
|
Extremely slow - takes between 3-10 seconds to respond |
Notes
Safari is sadly pitifully in the responsiveness of the various features we’ve tested against. Simply playing one of these high quality HD videos takes about 3-8 seconds to respond. Skipping ahead or back takes about 3-8 seconds, going to full screen and out takes about 3-8 seconds. Since the tests were performed multiple times on each browser at times it would take 10-15 seconds to respond to any of the actions listed.
Switching out of full screen mode has glitches as well. The video blanks out for a few seconds (still playing
but no picture) and then re-appears and continues as usual.
Hardware acceleration essentially means using the GPU (your graphics card) for compute intensive workloads. The typical $200 GPU has over 100 cores as compared to a $1500 CPU that has between 4 to 6 cores. So workloads can be parallelized across the cores in order to be done faster.
Video encoding and decoding (decoding is done during playback) are extremely well suited to being done using a GPU. So much so in fact, that these workloads are known as embarrassingly parallelizable workloads and what that means is that the more cores you have on your GPU (or CPU) the faster these workloads perform. Or the time it takes these workloads to finish is directly proportional to the number of cores.
From a video perspective, in order to use the hardware to decode (playback video), the video player needs to have a hardware decoder. For example, Flash player has a hardware decoder for H.264 on both Windows and MAC. Windows Media player and Quick time player both have a hardware decoder on their respective platforms.
In order for browsers to be able to use hardware acceleration for the purposes of video playback, each browser maker will have to have their own hardware decoders for the video codecs they intend to support. This also means that there is a potential for different performance metrics across browsers and platforms for the same codec (H.264, WebM, Ogg).
Hardware acceleration doesn’t stop at video encoding/decoding. Browser makers are beginning to use hardware acceleration for virtually every aspect of rendering. That is font rendering, graphics and layout rendering including (new to Html 5) SVG and Canvas. So what’s we’re going to see is that new browser are going to be really fast.
as it seems to be extremely good at making use of hardware acceleration for rendering. In fact it is blazingly fast and leaves all other browsers eating dust.http://ie.microsoft.com/testdrive/
