Streaming Learning Center

To add to this article. Did you know that only 2 out of the 7 demos found on Apple's HTML 5 showcase page actually used HTML5 http://apple.com/html5

It's amazing the levels of deception Apple and HTML 5 purits are willing to take to further their propoganda machine.

Actually didn't; thanks for sharing.

Jan

Great article Jan, well done and very informative.

Well written, and although clearly biased, still presented in a mostly "objective" statistics & data driven analysis. The bits on the HTML5 spec timeline I think are quite important. The worst thing with web development these days is having separate stylesheets for IE6/IE9/FF/Webkit/ etc etc .. now we will just have more layers of things that require various levels of falling back and customizations.

HTML5 fancy features aside, there is still a very large deficit with browsers and their rendering reliability of HTML/CSS. Everyone seems to avoid talking about the most common problems of web development are still right there, but with all the video codec hubub, they have gotten pushed to the side. Personally I wish video wasn't involved with HTML5, they should just focus on getting all browsers to be implemented the same way.

Thanks .... I think. I admit that I get pretty wound up with how biased the favorable HTML5 articles are,  with little or no facts to support their claims. All I can say is that you should have seen the first draft of this article - it was all bias and no fact. 

:-)

I agree that video has consumed a signficantly disproportionate share of the focus about HTML5 - Flash is dead just grabs more eyeballs than HTML/CSS. Let it do the basics first, then worry about video.

Thanks for sharing your thoughts.

Jan

It's funny how any Apple Fanboi will jump on Steve Job's every word and talk about how CPU intensive that Flash is...

Well the latest Google Doodle uses only JS and CSS has been crashing computers around the world because of the CPU demands.  HTML5 is a progression, but it's not the entire answer.

http://www.zdnet.co.uk/blogs/jacks-blog-10017212/g...

Mike:

Thanks for the kind words. As you probably noticed, the hype machine has been irritating to me as well, hopefully, this will add some balance.

Thanks for stopping by and for your comment.

Jan

Your analysis looks backward more than forward. Yes, the actual support and penetration of HTML5 video on the web is low at this point, but it's clearly the direction that the industry is going in. It's going to take a few years to get there, but I'd rather start experimenting with it now (I've got no other choice if I want to support iOS devices) than ignore it and have to make dramatic changes in order to keep up with architectural changes.

A few more myths would be.

1). Flash does not support touch. LIE!

2). Users lose browser controls like back button. LIE!

3). Not Seo friendly. LIE!

People use "flash amatuer" developers to base all of the negative on. Any one in the proffesional world knows that anything can be done with flash, and it can perform amazingly.

On a side note, looks like flash is getting native 3d support.

One thing people need to think about, is the commitees that developed some of the older specs didn't have a financal interest involved. The current commitees are made up of people in tech companies with strong financal interests, all the decisions are weighed against the interests of those businesses which means they are slow and contentious, and often lacking in inovation.

Good point, and I totally agree.

Thanks for contributing.

Jan

A quick correction: there's no DRM in HTTP Live Streaming - or at least no DRM in the sense that anyone would recognise it. The closest approximation is (per Apple's documentation):

Media files containing stream segments may be individually encrypted. When encryption is employed, references to the corresponding key files appear in the index file so that the client can retrieve the keys for decryption.

When a key file is listed in the index file, the key file contains a cipher key that must be used to decrypt subsequent media files listed in the index file. Currently HTTP Live Streaming supports AES-128 encryption using 16-octet keys. The format of the key file is a packed array of these 16 octets in binary format.

This is in no way equivalent to the protections available when using WMRM, FairPlay or FlashAccess; instead it's more like asking the consumer "promise you'll be good".

As i've written in my blog post, HTML5 Video – It’s a long way ’til JQuery, I see this as analagous to the spread of standards-based Javascript/DOM/CSS in the early 2000's.  lf you wanted a great/custom/interactive user experience on the Web back then, you had to build it in Flash or even as a Java applet. HTML4 offered things like layers and a DOM model and CSS, but browser incompatibilities and differing implementations made actually building anything using that technology an expensive, fragile affair. It was a still for science-fair projects and proofs-of-concept, not production apps.

Eventually, libraries like JQuery came about, which were made possible by browsers coalescing around standards - both official and defacto.  That gave devleopers an abstraction layer that allows the terrific web UIs we see today.  Less work, better features, better user experience.   

At this point, HTML5 video is still in that science-fair stage. Sure, you can use it, and to support Apple devices you have to. But it still offers less functionality for more effort, and as such, remains a necessary distraction for many video publishers at this point.

One day, it will be "there" and we'll love it like we love JQuery. But until then, Flash and Silverlight will provide the best path for supporting the most users with the best experience and the least effort.

Hey Larry:

Thanks for your insightful post. I would argue that when it's "there" Flash and Silverlight will be much further ahead, and there won't be there anymore. As I mentioned in a post on the StreamingMedia site,

"You seem to be saying that HTML5 can provide an effective lowest common denominator video playback experience. My point is that Adobe and Microsoft keep raising the floor as to what that lowest common denominator experience is, even for small corps."

But, you're closer to the firing line than I am, so your opinion has lots of weight with me, and I appreciate your sharing it.

Jan

This article defines the term "reality check," and blows away the smoke and mirrors. Thanks.

Jan, I should have said the same thing about the work you and Tim did last January in your articles on adaptive bitrate streaming. They were timely and truly helpful for those of us trying to make sense of this environment and build practical systems. Tech journalism can't do better than that.

:: SH

I think it's wrong to focus only on the video tag, which is only a tiny fragment of the HTML5 specs. In my opinion, HTML5 can be really useful to developers as it adds many semantic tags that helps structuring your HTML documents. I'll probably won't be using the video and audio tags for the next 4 years or so but I'll surely use the nav, arctivle, aside and other ones that will make my HTML more readable for my co-workers. Also it will help web spiders indexing pages more naturally, as crowlers will probably start ignoring navigationnal content and focus on the core content of pages.

Clement:

I agree, but virtually all of the positive press about HTML5 has been related to the video tag, starting with Apple's decision to not support Flash in the iPad.

Video or otherwise (of course), HTML5 won't really become practical until the installed base of HTML5 browsers gets much, much larger. I don't see that happending that soon.

Jan

You're right, the video tag does get most of the media coverage. The media (are they really knowledgable on the subject?) decided that highlighting this aspect would attract readers, mainly thanks to the hype around apple products and Job's refusal to integrate flash in iOS. I am kind of sad to see most of the attention of the develloper crowd focused on the video tag because of the media while other parts of HTML5 can be implemented right now! If you use a "aside" tag in your HTML it won't break the rendering in IE6 for instance.

Amazing eye-and-mind-opener article. A complement to Jan of course, but I also feel stupid not to have been critical enough to the no-to-flash-mantra of Steve Jobs. Our job is to deliver the best experience, if that goes well without Flash then go ahead! But based on many user engagement objectives, Flash does deliver a superior user experience IF developed by real Flash pros @truimagz. For instance, Flash supports alpha channels in video which can be interlaced seamlessly with content around it making a video sequence (like a moderator) an integral/interactive part of the experience http://active.tutsplus.com/tutorials/screencasts/g... . I don't know the specs of HTML5, so pls correct me if wrong, video is supposed to play in a box ... right?

Thank you for this excellent summary! As someone who is in the middle of a year-long Flash development project, I can now just send your link to all the people in my world who are freaking out over iPhones and iPads. You are absolutely correct that most of the Flash detractors are ill-informed about browser/device/video technologies. 

AC:

Glad to help; thanks for taking the time to write.

Jan

People really need to read this article, both programmers and web owners. There was some excellent information posted in this blog article. Thanks.

HLS may not be a full-fledged DRM solution however you can get pretty close.  Decryption keys should be unique for every video title and always delivered to the iOS client over a secure connection.  BTW, the "client" in this case is the native iOS player client which directy handles keys, decryption and playout.  Decryption key's for video playout are not handled by the browser and are therefore never exposed like they can be in a traditional web-based solution once they're transmitted.  Do you get playout protection with HLS... no.  So if this this is a non-starter for you then you don't really have a choice but to move to a full-blown DRM solution.  However, the security model can be made very tight and a no brainer if all you are securing is SD content.  Certainly worth a deeper dive when comparing the pains of implementing DRM and driving your customers crazy.  Content rights holders want DRM (i.e. studios), not customers.  There are good reasons for the consumer backlash against DRM and both complexity and infexibilty are among the biggest concerns.  Is HLS the Fort-Knox of security... no.  But you need to ask yourself if you really need that given the trade-offs you and your customers have to make with DRM.  Is HLS "enough" security... yes depending on what your protecting.  SD content in my opionion is a definite "yes".  Anything that minimizes that barrier for consumers should be seen as a good thing which makes HLS for iOS delivery a very viable option and one that should be seriously considered before moving to a full-fledged DRM solution.

Hey Mr. Video:

Thanks for your post - I thought HLS was iDevice only - does it currently work on Windows/Mac? If so, which browsers?

Please let me know - this sounds interesting.

Thanks.