After the debate around what it’s better at serving video between Flash and HTML5 I have found a lot of code in the Internet on how to serve video in HTML5 with a Flash fall back.
Independently by the fact that the debate is far from being concluded, I think that it’s a nonsense to check first for HTML5 and then for Flash instead of the contrary. Let’s follow this simple reasoning:
Today you have Flash Player in 98% of the desktops and on Android 2.2. Even excluding the fact that in a few months it will be available on RIM OS, Web OS, Windows Phone 7, Samsung and Sony connected TVs and Google TVs, the penetration of Flash Player is very very high because the computer’s desktop is still the most important place where Internet video are consumed.
The performance of Flash on these platforms is very good and I’m not speaking only about pure Fps or CPU usage statistics, but overall performance including video control, personalization, easyness of development, advertising compatibility, content protection and QoS. And now with StageVideo API the performance is very very good on Mac too.
On the other hand you have HTML5 which is a compact, standard and effective technology for video… Sorry, I correct myself: It WILL BE standard and effective because now it is a mess with every vendor implementing (or anticipating) the standard in its own way. It works well on Mobile, especially on iOS devices (even if the implementation does not adhere completely to the ‘draft’ standard), but on the desktop (over a Billion screens) it simply doesn’t work today, at least for video delivery.
The scenario is clear: On Desktop we have 50% of IE (sub 9) browsers who do not support HTML5 at all. 35% of Firefox browsers who support at the moment only Theora for video. Only Chrome and Safari seem to work flawlessly with HTML5, but yesterday Google has complicated everything announcing that Chrome will drop the support to H.264 in favor of VP8. It is definitely not a good scenario…
Therefore, I wonder, why should I serve my video first to HTML5 and THEN to Flash ? that would be crazy.
Use HTML5 as a Flash fall-back
You know that I develop video encoding pipelines as well as video delivery platforms and optimizations. So for my clients I propose Flash based players (custom or OSMF based). With Flash, not only they have the widest audience possible, but even a great and consistent interactive experience. Furthermore, one very important point for top media companies is content protection, and with Flash you can protect content in several ways. This is not possible today using HTML5 (indeed it’s also not possible to stream, you have only progressive dowloading), only iOS devices support a not standard streaming and protection schema.
But the new “Mobile Wave” cannot be ignored. Everyone want to watch video on iPhone, iPad or Android. And also BlackBerry, Symbian and Windows Mobile devices need to be served in some way.
So, what I propose to my clients ? The following Fall-Back approach:
IF The device has Flash (Desktop + Android2.2) THEN
…stream using Flash with Dynamic Streaming / Interactivity / Protection.
ELSE
……IF The device supports HTML5 (iOS, Android, etc…) THEN
………stream (on iOS) or progressive download (on Android and other webKit based browsers).
……ELSE
………serve video in a low end format for other devices in progressive downloading.
This kind of multiple fall-back schema can be achieved in several way. I like to use a compact schema, easily applicable for video that can be embedded in external pages. The example below uses the fall back feature of the HTML tag
<param name="movie" value="videoPlayer.swf?videoID=10" />
<param name="quality" value="high" />
<param name="allowfullscreen" value="true" />
<param name="allowscriptaccess" value="always" />
<param name="wmode" value="opaque">
</object>
First of all I have used two nested videoPlayer.swf?videoID=10 to your video player of choice). If even this second tag fails you are probably on a mobile device or on a tablet so it’s logic to try the HTML5 tag which works in IOS devices, Android and other OS with webkit based mobile browsers. The video tag allows to specify a list of possible video sources and tries to access them in sequence. Here I propose at first the Apple HTTP Live streaming technique serving the iPhoneVersion .m3u8 manifest file and only if this is not supported by the device I fall back to a progressive downloaded video in .mp4 format called AndroidVersion.mp4 (for Android, WebOS, RIM OS6, etc…). If even the tag fails you are probably on a early version of Android, Symbian, BlackBerry or Windows Mobile so a low end version of video is served in progressive downloading (LowEndMobileVersion.3gp).
This approach guarantee the best performance on desktop (Flash Player, streaming with bitrate switching, advanced QoS and protection) and on iOS (Apple HTTP Live streaming with bitrate switching and protection) where this schema works for both live and ondemand video. On the rest of the devices you can still serve on demand video without protection. It’s your video platform that must selectively built the right fall-back schema to exclude the lower version of video when it must be protected or if it is a live streaming.
Independently by the fact that the debate is far from being concluded, I think that it’s a nonsense to check first for HTML5 and then for Flash instead of the contrary. Let’s follow this simple reasoning:
Today you have Flash Player in 98% of the desktops and on Android 2.2. Even excluding the fact that in a few months it will be available on RIM OS, Web OS, Windows Phone 7, Samsung and Sony connected TVs and Google TVs, the penetration of Flash Player is very very high because the computer’s desktop is still the most important place where Internet video are consumed.
The performance of Flash on these platforms is very good and I’m not speaking only about pure Fps or CPU usage statistics, but overall performance including video control, personalization, easyness of development, advertising compatibility, content protection and QoS. And now with StageVideo API the performance is very very good on Mac too.
On the other hand you have HTML5 which is a compact, standard and effective technology for video… Sorry, I correct myself: It WILL BE standard and effective because now it is a mess with every vendor implementing (or anticipating) the standard in its own way. It works well on Mobile, especially on iOS devices (even if the implementation does not adhere completely to the ‘draft’ standard), but on the desktop (over a Billion screens) it simply doesn’t work today, at least for video delivery.
The scenario is clear: On Desktop we have 50% of IE (sub 9) browsers who do not support HTML5 at all. 35% of Firefox browsers who support at the moment only Theora for video. Only Chrome and Safari seem to work flawlessly with HTML5, but yesterday Google has complicated everything announcing that Chrome will drop the support to H.264 in favor of VP8. It is definitely not a good scenario…
Therefore, I wonder, why should I serve my video first to HTML5 and THEN to Flash ? that would be crazy.
Use HTML5 as a Flash fall-back
You know that I develop video encoding pipelines as well as video delivery platforms and optimizations. So for my clients I propose Flash based players (custom or OSMF based). With Flash, not only they have the widest audience possible, but even a great and consistent interactive experience. Furthermore, one very important point for top media companies is content protection, and with Flash you can protect content in several ways. This is not possible today using HTML5 (indeed it’s also not possible to stream, you have only progressive dowloading), only iOS devices support a not standard streaming and protection schema.
But the new “Mobile Wave” cannot be ignored. Everyone want to watch video on iPhone, iPad or Android. And also BlackBerry, Symbian and Windows Mobile devices need to be served in some way.
So, what I propose to my clients ? The following Fall-Back approach:
IF The device has Flash (Desktop + Android2.2) THEN
…stream using Flash with Dynamic Streaming / Interactivity / Protection.
ELSE
……IF The device supports HTML5 (iOS, Android, etc…) THEN
………stream (on iOS) or progressive download (on Android and other webKit based browsers).
……ELSE
………serve video in a low end format for other devices in progressive downloading.
This kind of multiple fall-back schema can be achieved in several way. I like to use a compact schema, easily applicable for video that can be embedded in external pages. The example below uses the fall back feature of the HTML tag
<param name="movie" value="videoPlayer.swf?videoID=10" />
<param name="quality" value="high" />
<param name="allowfullscreen" value="true" />
<param name="allowscriptaccess" value="always" />
<param name="wmode" value="opaque">
</object>
First of all I have used two nested videoPlayer.swf?videoID=10 to your video player of choice). If even this second tag fails you are probably on a mobile device or on a tablet so it’s logic to try the HTML5 tag which works in IOS devices, Android and other OS with webkit based mobile browsers. The video tag allows to specify a list of possible video sources and tries to access them in sequence. Here I propose at first the Apple HTTP Live streaming technique serving the iPhoneVersion .m3u8 manifest file and only if this is not supported by the device I fall back to a progressive downloaded video in .mp4 format called AndroidVersion.mp4 (for Android, WebOS, RIM OS6, etc…). If even the tag fails you are probably on a early version of Android, Symbian, BlackBerry or Windows Mobile so a low end version of video is served in progressive downloading (LowEndMobileVersion.3gp).
This approach guarantee the best performance on desktop (Flash Player, streaming with bitrate switching, advanced QoS and protection) and on iOS (Apple HTTP Live streaming with bitrate switching and protection) where this schema works for both live and ondemand video. On the rest of the devices you can still serve on demand video without protection. It’s your video platform that must selectively built the right fall-back schema to exclude the lower version of video when it must be protected or if it is a live streaming.
إرسال تعليق