Also recently, Steve Jobs, co-founder and CEO of Apple Inc, has made it very clear that Apple wants nothing to do with Adobe Flash calling Adobe "lazy" and Flash "buggy". These seem to be the only two reasons given thus far for not supporting Flash on the iPhone, iPod Touch and iPad. At the same time, Mr. Jobs is pushing the HTML5 agenda as a replacement for Flash even though the spec is far from being complete.
There are several technical and political decisions to be made concerning the HTML5 spec, among these the choice of video codec(s) to support. In one corner you have H.264 (MPEG-4/AVC), an industry standard which is supported by nearly every device from mobile phones, iPods, and browser plugins including QuickTime, Silverlight and Flash. In the other corner, Ogg Theora, an open source alternative which is unsupported on most devices and is based on the ancient On2 VP3 codec. But it's free from licensing fees.
Content producers should be actively engaged in this debate. From purely a workflow standpoint, HTML5 could alter how assets are encoded. If Ogg Theora is chosen the amount of time required to render yet another file, distribute it, and figure out a way to intelligently stream it is not a simple task. And if H.264 is chosen, nothing really changes. The MP4 files you're already encoding for QuickTime, Silverlight or Flash will continue to work. The worst thing that could happen however, is if this piece of the HTML5 spec is left unfinished and no recommendation is made, leaving browser vendors and content producers open to interpret the spec differently.
Websites use Flash for varying reasons; some for animation, some for interactivity and some for content delivery. HTML5 will eventually replace Flash for simple tasks once the spec is complete and tools are created to assist with authoring. What HTML5 will never do is replace Flash (or Silverlight for that matter) in content delivery.
The ability to deliver content reliably and in a timely manner is not something the Hypertext Transfer Protocol (HTTP) protocol was designed to do. It was designed to transfer hypertext, or HTML. To ensure a more robust streaming experience, other protocols were devised, namely Real Time Streaming Protocol (RTSP, supported by QuickTime and Silverlight) and Real Time Messaging Protocol (RTMP, supported by Flash). These protocols have a few things in common. They provide real-time streams of audio and video, can support live streaming events, allows a user to jump to an exact point in time in the video (not just the nearest keyframe), will gracefully alter the quality of the content based on the bandwidth available, and can support Digital Rights Management (DRM). Additionally, Flash offers the ability to capture the local webcam and microphone and stream it to the server for archiving and/or redistribution.
HTML5 does not address any of these things. Now, if you're a large video sharing site like YouTube with millions of 1-5 minute community-generated clips, having a quality viewing experience at all bitrates while supporting millions of concurrent live streams, and protecting the producers content during the delivery process is simply not required. In fact, the basic HTML5 video capabilities are probably good enough. However, if your business model is to make money from the content on your site though subscription services, or simply want the best user experience possible, then Flash (or Silverlight), not HTML5, is the best choice. Sites like Hulu that use RTMP in the Flash platform could not offer the kind of experience they do today by using HTML5 exclusively. It's simply not possible.
So for the Flash-haters and those blinded by the HTML5 hype, go back to the 1990's Internet and experience how bad content delivery can be without the support of streaming protocols.
All of this makes me wonder... Mr. Jobs, after the sell of Pixar to Disney, has more shares of Disney than any other individual and is a member of Disney's board of directors. Wouldn't Jobs want Disney's content to be delivered in the best possible way while simultaneously protecting it and making it easily accessible through any web browser? A reasonable and responsible answer would be 'yes'. But Mr. Job's recent actions and statements contradict this in favor of the expectations of yesterdays technology.







The ability to find differences in source code files and merge
conflicts if they arise is a basic task that every programmer requires.
Utilities that perform this task are part of every programmers arsenal.
So it came as quite a surprise that the selection for such tools on the
Mac (a fantastic development platform) was extremely limited.![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=9547cddf-6ab1-4671-adcd-59582f710a1e)

![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=0ee0dad0-3456-4e45-9c7e-c89b2395b230)




This is the personal weblog of Steve Springett, a professional web designer and software developer who specializes in internet delivery of audio and video.