Wednesday, June 30th, 2010

HTML5 Video; YouTube Perspective

Category: Video

The YouTube API blog put their point of view on HTML5 video on the table. I would love to know why they felt like this was the right time, and what their angle is. I find myself often confused with the Google strategy. On one hand they are doing amazing things for the Open Web (Chrome, tools, Steve Souders and Web performance work), but on the other we see an alignment with Adobe and Flash (a differentiator to Apple).

Man, I am torn. The pragmatist totally gets it. But the guy who realizes that it was the Web openness that allowed the likes of Google come from nothing to the powerhouse that it is today in a decade, gets confused.

If you are a Flash fan you see this as “see! Flash is here to stay!” As someone who wants to see the Web standards get better fast, we see some of the momentum (fact that we have audio and video, and the WebM codec) and features that we need to get in:

Robust video streaming

Closely related to the need for a standard format is the need for an effective and reliable means of delivering the video to the browser. Simply pointing the browser at a URL is not good enough, as that doesn’t allow users to easily get to the part of the video they want. As we’ve been expanding into serving full-length movies and live events, it also becomes important to have fine control over buffering and dynamic quality control. Flash Player addresses these needs by letting applications manage the downloading and playback of video via Actionscript in conjunction with either HTTP or the RTMP video streaming protocol. The HTML5 standard itself does not address video streaming protocols, but a number of vendors and organizations are working to improve the experience of delivering video over HTTP. We are beginning to contribute to these efforts and hope to see a single standard emerge.

Content Protection

YouTube doesn’t own the videos that you watch – they’re owned by their respective creators, who control how those videos are distributed through YouTube. For YouTube Rentals, video owners require us to use secure streaming technology, such as the Flash Platform’s RTMPE protocol, to ensure their videos are not redistributed. Without content protection, we would not be able to offer videos like this.

Encapsulation + Embedding

Flash Player’s ability to combine application code and resources into a secure, efficient package has been instrumental in allowing YouTube videos to be embedded in other web sites. Web site owners need to ensure that embedded content is not able to access private user information on the containing page, and we need to ensure that our video player logic travels with the video (for features like captions, annotations, and advertising). While HTML5 adds sandboxing and message-passing functionality, Flash is the only mechanism most web sites allow for embedded content from other sites.

Fullscreen Video

HD video begs to be watched in full screen, but that has not historically been possible with pure HTML. While most browsers have a fullscreen mode, they do not allow javascript to initiate it, nor do they allow a small part of the page (such as a video player) to fill the screen. Flash Player provides robust, secure controls for enabling hardware-accelerated fullscreen displays. While WebKit has recently taken some steps forward on fullscreen support, it’s not yet sufficient for video usage (particularly the ability to continue displaying content on top of the video).

Camera and Microphone access

Video is not just a one-way medium. Every day, thousands of users record videos directly to YouTube from within their browser using webcams, which would not be possible without Flash technology. Camera access is also needed for features like video chat and live broadcasting – extremely important on mobile phones which practically all have a built-in camera. Flash Player has provided rich camera and microphone access for several years now, while HTML5 is just getting started.

Time to knuckle down and deliver great new video features in the browsers!

Posted by Dion Almaer at 6:16 am

3.8 rating from 5 votes


Comments feed TrackBack URI

Nevertheless not a so big issue but Youtube needs more feature than HTML5 provides.
What is missing on HTML5 is an access on more specific resource of the hardware (specific navigation of smart phone for instance or controller on WII)
I’m writting an article (not yet finished) as an answer to this post
see it at
Anyway it seems clear that a native HTML5 video solution should be created as proof of work.
If people are interested please contact me on my blog.

Comment by 4proweb — June 30, 2010

I am very confused about the encapsulation and embedding part since it’s simply … wrong. As far as I know (which admittedly isn’t very far) Flash’s primary security mechanism is identical to HTML’s: If something from a foreign domain is embedded, it remains in the security context of the domain hosting the remote content. So, a document loaded from can only affect other pages, no matter from where I load it. The same is true for HTML.

As far as VIDEO itself is concerned (which isn’t very far, since YouTube will want people to embed their player, not just the video), it can be embedded anywhere without security issues.

Comment by hansschmucker — June 30, 2010

@hans – the equivalent to a single flash video player SWF file (+ its FLV video file or video stream) in HTML5 technology would be JavaScript code to embed a <video> tag, as well as JavaScript and CSS to style it and its controls.
The difference is that with a .SWF, as you said, it will operate in the security context of the domain ( it comes from, meaning it can’t maliciously screw with the page. But if I load JavaScript from another domain, that JavaScript runs in the context of MY page, not from where it came. So it has full control to mess with my page’s content if it wants to (or does so accidentally).
Pretty sure that’s what they mean by the difference in encapsulation.

Comment by getify — June 30, 2010

@getify But isn’t that comparing apples to oranges? To me it would still read like:
Flash is great because it allows embedding whole documents without security issues.
HTML is bad because it only allows embedding whole documents without security issues.

Flash may have a system for importing ActionScript from a foreign domain and evaluating it in a separate security context, while at least backwards-compatible HTML+JS needs hacks for that, but I can’t really see the relevance for VIDEO+HTML+JS which needs a hosting document anyway in order to deliver the HTML needed for the player that YouTube wants to see embedded.

Just deliver an iFrame and you even get Flash-compatibility free of charge, since the iFrame can then load Flash components if HTML VIDEO isn’t available.

Comment by hansschmucker — June 30, 2010

Its not so much the security issues which present challenges when it comes to video embedding – its a big part of it, and as the article says, both HTML5 and Flash have allowances for sandboxing but the key roadblock is “Flash is the only mechanism most web sites allow for embedded content from other sites.”.

Coming from a startup which creates videos, the biggest challenge is when our users want to embed their videos on their own websites, within CMS’s, Blogs etc. Many of which place restrictions on the types of content a user can embed. Usually script tags, iframes and anything exotic is not allowed. Flash already has their foot in the door here, with near-universal support for object/embed tags in the leading blog and CMS platforms.

If we as embed code providers switched to HTML5 overnight, we would be waking up to many emails from unhappy customers who don’t understand why they can no longer post videos to their blogs. Support for HTML5 video embeds would need to happen on the vendor end, and customers would need to adopt it – a process which could take years.

Based on this, I totally understand why YouTube is sticking with Flash for the time being.

Comment by ckorhonen — June 30, 2010

I can understand that from a practical point of view, but does it make sense to complain about the spec when you really want to criticize such a situation? What could the W3C possibly do about this?

Comment by hansschmucker — June 30, 2010

I didn’t get the feeling YouTube were complaining about the spec in this instance, they note that HTML5 has sandboxing and message passing functionality in the spec, but practically, Flash is the allowed mechanism for most websites.

Its only really when they are talking about streaming protocols where they criticize the spec, and its certainly one place where I feel the W3C hasn’t really considered the real world needs.

Comment by ckorhonen — June 30, 2010

Different people, different impressions :)
Considering the way it was posted (shortly after the parent company has made a significant contribution the HTML5 camp), I looked at this primarily as a list of things YouTube wants from the W3C in return.

Comment by hansschmucker — June 30, 2010

Google and YouTube obviously wants HTML5 video to succeed, but at the same time they have to be realistic on where it is today and how far it has to go. I imagine this post was in response to the many requests that YouTube has been getting from other developers to switch their main player to HTML5. I think that was why this post is on the YouTube API blog, instead of elsewhere.

Also out of those issues, I think the content protection is going to be the big one that I’m not sure will ever be implemented in browsers. As with all the fights going on about video codec, I don’t see how browsers can ever all agreeing to some sort of DRM to stop users from downloading a video stream. I think there will always be a place for plugins when it comes to high-quality content (tv networks, movie studios, etc.) in order for them to protect their content.

Comment by MatthewFabb — June 30, 2010

I wonder what HTTP streaming technologies they are actually looking at. Apple’s HTTP streaming is a proposed standard and does a lot of what they are saying is a limitation of HTML5. It would be nice to see them offer a standard of their own or just adopt the one by Apple.

Comment by carsonm — July 1, 2010

content protection is a bad joke. when you publish, you publish.

Comment by loveencounterflow — July 6, 2010

Leave a comment

You must be logged in to post a comment.