Comments Off

By Larry B, March 1, 2010

Is Flash video on a Mac a CPU hog?  More than on Windows? If so, why?



Thankfully, someone’s finally done a test to put some data behind the anecdotes.  (Doh!  Why I didn’t think of doing that?!?) Jan Ozer over at the Streaming Learning Center hastested Flash video vs. HTML5 video, covering all the browsers on both Windows and (Intel) Mac, and Flash versions 10.0 and (the new, performance-optimized) 10.1.



It’s hard to summarize the findings without leaving out important detail, so I recommend looking at Jan’s data directly.  The tables are revealing.  But in a nutshell, Jan found that where the video decoder can access hardware acceleration, performance is excellent, and where it can’t…not so much.  This means that on Windows, Flash is actually slightly more CPU-efficient than HTML5. On the Mac, where Apple has not made API hooks to its graphics hardware acceleration available to software developers, Flash and HTML5 are both hogs – unless you’re using HTML5 in Safari.  It suggests that Apple is using graphics acceleration APIs that it’s keeping from others who are developing applications for the Mac. (Kinda smells like what Microsoft was accused of years ago – keeping various Windows APIs secret so that its non-OS products would always have an advantage over  competitors. Microsoft has denied this. )  



Is it fair – or smart – to withhold powerful APIs from the devleopers who create the applications that make your computer useful and relevant to users?  At best. it’s disingenuous for Apple to criticize Adobe for Flash performance on the Mac while keeping access to hardware acceleration under wraps.  



In any case, Jan’s tests show that Adobe is continuing to work on this (to the extent that it can).  Video performance in Flash 10.1 is improved over 10.0 on both Mac and Windows. On Windows, the difference is dramatic.

Bookmark to:

Comments Off

By Larry B, February 26, 2010

I had the distinct pleasure of attending Lawrence Lessig’s talk at Harvard Law School on behalf of the Open Video Alliance.  It was a terrific event, simulcast worldwide to dozens of screening locations using entirely open technologies; in particular, HTML5 and the Ogg Theora video codec.

Interesting side note that the session was funded in part by iCommons, the open standards/knowledge/software advocate; while I work at iCommons, Harvard University’s academic computing team.  I kept hearing “iCommons” mentioned, and it took a moment to recognize that it was another iCommons.  But I digress….

Lessig’s talk was great. The parts about open software, open standards, and the architecture (both legal and technical) of the read/write culture mirror closely the points in his books, and are eye-opening.  If you’ve not read Remix: Making Art and Commerce Thrive in the Hybrid Economy, you ought to.

But what I was really wondering about most during this talk was the open video concept and mention of the “Flash problem”.  Seems the Ogg Theora codec and HTML5 are seen as potential resolutions of a huge problem — the problem of proprietary video codecs and players. But as someone who builds, buys, deploys, and manages streaming video platforms and content, I couldn’t quite come to terms with all that I’d have to give up if I replaced the Flash Player in my solutions with HTML5 and Ogg.  Flash’s universality has been a tremendous boon to online video. Those of us who remember the format wars — Real vs Windows Media vs Quicktime, platform-specific plugins, single-platform codecs, browser incompatibilities — Flash is a breath of fresh air compared to that.  Being able to support a single set of APIs and codecs for all my users has been huge.  And, using a mature player such as the JW FLV Player,  being able to do stuff like:

• support for rtmp or http streaming
• callback event-based client-side scripting
• playlist support (RSS, ATOM, XSPF)
• bandwidth switching/adaptive streaming
• plugins for screengrabs or stats collection
• subtitles
• control over buffering

I can create an outstanding user experience using these tools, and do it for more than the degenerate case of simply putting a video in the page.  All sorts of interactive behavior can be easily layered into my video apps, and with no browser dependencies to worry about.

Contrast that with my first experience showing HTML5 video to a non-techie, my wife.  At the end of Lessig talk, the Open Video Alliance announced the winners of the Open Video in 60 Seconds contest, which gave contributors 60 seconds to explain open video using video.  One of the entries, (not the winner, although IMHO it should have been) was by Rafaella, a teacher from Italy who did an outstanding job showing that all creativity is but a link in a long chain of the creative contributions of others.  I came home eager to show my wife, who I thought would really appreciate it.

At the conference, it was played in Quicktime with English subtitles. At home, I quickly found it on the Web, in the HTML5 player….with no subtitles.  Huh?  You gotta be kidding me!   Helpfully, a download link is provided to the .srt file containing the subtitles. That’s helpful. After all, of course I’d want to read this in an open texteditor alongside my video:

Thankfully, a link was also provided to the original source site for the video, which offered a subtitled version, in…..you guessed it…Flash.

So….the Flash-based video world is seen as proprietary, which it is.  But as an applications guy, what makes a platform proprietary to me?  Vendor lock-in. Platform lock-in. Client-server dependencies.  I don’t really see this as a huge problem in Flash video.  I can deliver videos in Sorenson, On2, or MPEG4 codecs. I can use players by numerous vendors, or roll my own for free with the Flex SDK. I can serve video from any server, from FMS 3.5 to Apache to Wowza. I can switch from rtmp to http, or from Akamai to a free server under my desk. Or I can dump Flash and play the same MP4 content in Quicktime, RealPlayer, or Silverlight.  I’m not getting that proprietary locked-in feeling, really.

So what’s my point?  Not that Open Video is a bad idea….I think it’s wonderful. I love vendors with an open mindset and open products, like Kaltura.  Imagine when browser support for video approaches the support now universal for DOM scripting, Javascript, AJAX, etc. Powerful toolkits like JQuery and ExtJS are only possible because of the support for standards in the browser.  And, crucially, these toolkits have made it possible to do things in the browser that previously could only be done with Flash. There are some demos that show the promise of attractive, plugin-free Web video, although compatibility and functionality are still in a nascent stage.

But as a real working technologist solving problems on the ground every day, I don’t entirely understand the “Flash problem”.  I don’t want to employ closed technologies that narrow my options and lock me in, but I’m not seeing Flash as being that way very much when it comes to video.  But I’m eager to be educated.

[amtap book:isbn=1594201722]

Bookmark to:

Comments Off

By Larry B, January 6, 2010

A test of the Wordpress Kaltura Plugin. Interesting how they’ve implemented this. I love the idea, and the design of the API.

Interesting, too, that my first upload, an h.264/AAC Quicktime file (.mov) will not work. Kaltura lets me upload the file, name it, and insert into the page. At that point, what you see here is what there is.  No error message, no indication of what’s wrong. Just no video.

[kaltura-widget wid="" width="400" height="290" addpermission="" editpermission="" /]

With a little more digging, it appears to be an issue with the Kaltura WordPress plugin rather than the Kaltura server-side app. I can log in to the Kaltura Management Console and play the video there, but the EMBED statement Kaltura plugged into this page is lacking some necessary parameters. I has worked in the past….so it’ll take some investigation to see what’s broken, exactly.

[ADDITION: 2.26.2010]

OK…so it turns out not to be a Kaltura problem at all. The problem was the WYSIWYG editor in Wordpress itself. When Kaltura inserts the video player tag into the blog entry editor, it does so in raw HTML mode, and it does so correctly.  Problem is that if you happen to switch back to WYSIWYG, the editor clobbers the video tag Kaltura inserted, clearing out a bunch of important tag attributes. Mystery solved. Kaltura is not at fault!

Bookmark to: