TheRealTimeWeb.com - Videos & Players

Microsoft Releases HTML5 Video Player Framework

Thu, 08 Sep 2011 12:49:00 +0100

The following tweet by Mike Downey caught my eye this morning. He announced that Microsoft have released Player Framework, which in their words is 'an open source video player framework for HTML5, Silverlight, Windows Phone and other application platforms'. Upon closer inspection it is the former Silverlight Media Framework, shifted towards HTML5.

It's interesting to note that this Player does not use Flash as a fallback technology, but enables developers instead to use Silverlight, or indeed choose from a variety of combinations such as HTML5 only (video tag), Silverlight only, fallback to HTML5 or fallback to Silverlight.
Whilst the player itself looks as one would expect, offering features such as mute, poster frame and full screen mode it also claims to add support for plugin models, advertising standards support, W3C timed text (TTML) for captions amongst other things.

What the demo also shows is the effort involved in providing a consistent cross platform experience when using the video tag. I'm not sure why, but when I tried the demo in FireFox on my Mac the 'Fallback to Silverlight' went straight to Silverlight and did not play the HTML5 content, but the HTML-only tab worked fine. Moreover since Silverlight does not seem to be compatible with the 64bit mode of my browser I saw no content at all, just a prompt to install Silverlight (which I am sure I already had installed - but maybe only a 32bit version?). I guess we can blame this on the beta status of the framework. But why not fall back to Flash anywhere? Is it really just because Flash-hating is a sport these days, or do companies simply not care about providing a good user experience? Is it too much to ask to detect the fact that I cannot run Silverlight and serve up a SWF instead?

Fullscreen mode is another sore point it seems. Whilst the framework claims to support fullscreen mode it really is just a full-browser mode - that's not full screen in my book. I also noticed some audio problems which surfaced in a delay when mute and unmute was selected.

All in all I congratulate Microsoft for putting in some effort and I am sure adding Flash fallback (let's be serious here: it makes a lot more sense than Silverlight fallback) would not be too difficult.
The plugin architecture of the framework also looks very useful, and some of the core features of the player are implemented in that way, with JavaScript providing the glue to it all.

You can check out the player demos here.

Dynamic Streaming Using F4M And Flash Media Playback Via CloudFront

Sat, 07 May 2011 15:31:00 +0100

Here is a quick heads up on an issue you may encounter when streaming video using Flash Media Playback and f4m files to provide dynamic streaming whereby the player will automatically pick the correct bitrate version depending on the user's connection speed.

In my case I wanted to stream my videos using Amazon's Cloudfront service. A typical RTMP URL will look something like this: rtmp://saaabbbccc.cloudfront.net/cfx/st/mp4:myvideo.mp4 If you go ahead and create an f4m file using this you may end up with something like the following (presuming 3 bitrates at 500, 1000 and 1500 kbps): Dynamic Streaming video/mp4 rtmp://saaabbbccc.cloudfront.net/cfx/st Unfortunately this file will not work when fed into Flash Media Playback. The reson (and fix) is quite simple and one some of us may remember from using the FLVPlayback component in Flash. It is a missing application instance name. In our case this is the default instance _definst_ that needs to be added to the baseURL. The correct f4m listing would therefore be as follows: Dynamic Streaming video/mp4 rtmp://saaabbbccc.cloudfront.net/cfx/st/_definst_ I hope this helps someone. I was slightly confused by this as any one of my files would play fine using the FLVPlayback component without specifying the _definst_ in the video RTMP URL.

And one final gotcha: if you host your f4m files in an Amazon S3 bucket (but not your streaming bucket, you need to use a separate non-streaming bucket for non-video files) you may require your own crossdomain file inside it or the Adobe hosted Flash Media Playback SWF won't be able to load it.

A free tool to help you manage your S3 buckets (if you are on Windows - I run this tool in a VM) is CloudBerry Explorer. It's one of the better S3 related tools out there. Do you know an equally good one for OSX?

Google Removes H.264 Support From Chrome

Tue, 11 Jan 2011 22:33:00 +0100

It has only been a few minutes since the news of Google removing support for the H.264 video codec from Chrome in favour of WebM, a codec that Google open-sourced after their acquisition of On2, has been making the rounds. Is this significant? I guess it depends who you ask, but Chrome is certainly a browser that's quickly gaining traction, and rightly so.
I personally have seen very few videos in H.264 on the web that were *not* played back in Flash. Since Flash (as well as other plugins) will of course still be supported in Chrome there is always that option (with the notable exception of Apple's iDevices of course since none of those support Flash or indeed other browser plugins).

Adobe have already publicly committed to supporting WebM in Flash, and joined Google alongside many other companies on the WebM project. A notable exception on that list is of course Apple, an avid supporter of H.264. But it remains to be seen if Google's decision has any real implications in the short term. Things would look differently if YouTube was to stop encoding videos to H.264 and 'force' anyone wanting to play back new videos using a platform or browser that supports WebM.

Another party not to be pleased is undoubtedly MPEG-LA, the organisation responsible for setting and collecting licensing fees for H.264. Let's not forget: despite what Apple would like you to believe, H.264 is neither open nor free, and many companies including Adobe pay huge sums (millions I assume) to MPEG-LA in order to be able to add the H.264 decoder to Flash Player and other tools. And as John Dowdell confirmed, "when I've asked, I've heard 'millions' quoted for redistribution licensing as well." No small change then.

What does this mean for Flash? It could solidify its position as the safe bet for video playback on the web. There is little chance of Adobe removing support for H.264, and they are definitely adding WebM.

In the long run I'm not sure if Flash will remain the primary choice for video playback on the web. But as long as the rest of the landscape is in such a mess I cannot see it going away anytime soon. My prediction is that we will still see a lot of Flash based video being deployed in 10 years from now.

Learn All About Strobe And ActionScript-only Video Players

Mon, 15 Nov 2010 22:04:00 +0100

Mark your calendar for this coming Wednesday, 17th November 2010. The OSMF User Group is hosting an online event to which everyone is welcome; the title:
Building ActionScript-Only State-of-the-Art Video Players -- An In-Depth How-To Code Walkthrough (Using Codebase of Open Source Strobe Media Playback)

The session is an online code walk-through of the open source Strobe Media Playback video player codebase.

The code walk-through will be led by Andrian Cucu who is Adobe's Project Leader on the Flash and Strobe Media Playback video player project.

To join, just go to the following link at the meeting time to join the OSMF User Group's Connect room:
http://experts.na3.acrobat.com/osmf/

For further details and to RSVP see the following link: http://osmf.groups.adobe.com/index.cfm?event=post.display&postid=30846

Does HTML5 Video Playback Hog More CPU Than Flash?

Sun, 28 Feb 2010 21:55:00 +0100

This is not a trick question, but more of a pushback on the recent FUD that various people have been spreading. Quotes such as 'HTML5 video uses 10% CPU while Flash uses 100%' were both unprofessional and not backed up by any actual data. The short answer to the above question could in fact be yes - if I wanted to spin these results, but the more correct way of putting things would actually be: 'It depends'.

My co-author Jan has gone through some lengths to come up with the most thorough like-for-like comparison of HTML5 versus Flash video decoding requirements as far as CPU usage is concerned. His conclusions follow below, and I recommend you head over to his blog for the full story.

=======================================
Overall Conclusions
When it comes to efficient video playback, the ability to access hardware acceleration is the single most important factor in the overall CPU load. On Windows, where Flash can access hardware acceleration, the CPU requirements drop to negligible levels. It seems reasonable to assume that if the Flash Player could access GPU-based hardware acceleration on the Mac (or iPod/iPhone/iPad), the difference between the CPU required for HTML5 playback and Flash playback would be very much narrowed, if not eliminated.

I don't follow the politics of the situation, but after noting significant playback efficiencies in Flash Player 10.1 on the Mac, respected technologist and AnandTech founder Anand Lai Shimpi commented "with actual GPU-accelerated H.264 decoding I'm guessing those CPU utilization numbers could drop to a remotely reasonable value. But it's up to Apple to expose the appropriate hooks to allow Adobe to (eventually) enable that functionality." So it looks like the ball is in Apple's court.

Overall, it's inaccurate to conclude that Flash is inherently inefficient. Rather, Flash is efficient on platforms where it can access hardware acceleration and less efficient where it can't. With Flash Player 10.1, Flash has the opportunity for a true leap in video playback performance on all platforms that enable hardware acceleration.

Turning full circle, if Anand is right, and I don't doubt that he is, Apple complaining about Flash being a CPU Hog while not exposing "the appropriate hooks" to enable Adobe to access hardware acceleration seems disingenuous at best. To be fair to Apple, though, the iPad related timing was unfortunate, with the bulk of the development work done under the shadow of Flash Player 10.0, which didn't offer hardware acceleration other than full screen on any platform and was clearly less efficient than the HTML5-based approach Apple adopted. Now that Adobe has proven the concept on Windows, perhaps Apple will cooperate with Adobe to make hardware acceleration on the Mac, iPad and future devices happen. If they choose not to, however, they should quit pointing fingers at Flash.

What else? We also learned that not all HTML5 browsers/H.264 decoders are created equal. Significantly, with Flash 10.1 deployed, Google's HTML5 implementation required the most CPU horsepower of all playback scenarios -- by far -- on the Windows platform. On the Mac, Firefox and Safari with Flash required less CPU horsepower than Chrome's HTML5 implementation.

At least from a CPU utilization perspective, Flash isn't BAD and HTML5 isn't GOOD. It all depends upon the platform and implementation.
=============================

For the full test procedure and detailed results head over to Jan's blog.

Ogg Theora versus H.264 Video Quality Shootout

Sun, 21 Feb 2010 21:27:00 +0100

My friend Jan has published some quality comparisons between the Ogg and H.264 video codec. For those who don't know, Ogg Theora is the video container format and codec favoured by Mozilla for playback of web video in HTML5 whereas H.264 is a widely popular codec - one may say the industry standard - that is used for all types of content from Flash (on sites that include YouTube and Hulu) to Blu-Ray and DVB broadcast television.

I can't say that I'm surprised about Jan's test results in which H.264 comes out on top. Ogg Theora is quite a dated codec which is based on Ons'2 VP3 specs, and which has become a free, open standard. Unfortunately the label of free software alone does not guarantee that Ogg Theora won't be vulnerable to yet unknown patents. For those reasons I would personally be very surprised if Ogg Theora sees any significant uptake in the future, even once HTML5 becomes more widely supported. Major players such as Apple and Nokia were amongst those who opposed the inclusion of this specific format as part of the proposed HTML5 specs, and it is highly doubtful that Mozilla alone has enough leverage to give this compression format a new lease of life.
Meanwhile both Safari and Chrome are focused on supporting H.264 which they consider to be a better choice for web video.

Check Jan's full article here and stay tuned for some more video codec specific tests in the coming weeks.

Flash Video versus Desktop Video - Apples and Oranges

Fri, 29 Jan 2010 13:56:00 +0100

Amongst all the noise that is currently being emitted after the ~~jesus~~iPad announcement there are a also some high quality gems of content emerging, and Mike Melanson's piece on the different problems which the Flash Player solves when it comes to video delivery is one of them.

In particular Mike explains how a desktop video player and Flash Player differ. One obvious difference which surprisingly often gets overlooked, is that Flash Player is not just a video delivery medium but so much more than that. If you think back a few years there was barely any support for video in the Flash Player, and the only reason we hear so many complaints about its performance is due to the fact that so many people are using it these days. Flash has had an unprecedented growth curve when it comes to video delivery on the web, but it was a popular plugin way before then.
The issue Mike explains well in his article is that of users comparing apples to oranges a lot of the time: they compare a browser plugin to a desktop tool. In Mike's words, "a desktop player usually plays a linear media file from start to finish. Flash Player solves a different problem: It plays linear media files from start to finish while combining the video with a wide array of graphical and interactive elements (buttons, bitmaps, vector graphics, filters), as well as providing network, webcam, and microphone facilities, all programmable via a full-featured scripting language, and all easily accessible via a web browser using a plugin that most of the browsing population already has installed."

Mike's article in full can be found here. Please bookmark it and send to everyone who asks you next time: "Can you explain why a video player like VLC can play the same flv file with less CPU usage than the Flash Player?".

And the main takeaway: "The Flash Player works to solve the problem of making video accessible via the web browsing environment. In contrast, a desktop media player plays a file using a dedicated, single-purpose application."

Dynamic Bitrate Streaming Demo

Tue, 17 Nov 2009 23:57:00 +0100

I'm finally finding a bit of time (at 10pm) to upload a little video demo that had been sitting on my hard drive for a couple of months. The premise was that I wanted to have a play with the new dynamic bitrate streaming feature in Flash Media Server so I grabbed a trailer from Apple's website, fired up Flash Media Encoder and encoded the District 9 HD clip into 3 bitrates to .f4v format: 400kbps (low bitrate), 800kbps (medium bitrate) and 1.5mbits (high bitrate).
Video quality was not my primary goal here (as you can probably see from the footage), instead I just wanted to see how hard or easy it is to get something like this up and running. Bottom line: not too difficult at all.
I've got a copy of FMS 3.5, a dedicated server (UK based) with a decent bandwidth allowance so I figured why not release this into a the wild?
One thing that you should pay attention to is the actual bitrate switching. If your connection speed is very stable then you may right-click the player and choose to manual switching - let me know if you can tell when the delivered bitrate changes, I bet you can't. And that's the beauty of this technology in a nutshell: seamless switching between bitrates. Pretty neat. Note you can also click the little HD icon/bandwidth bar to bring up a console with stats about the video and playback.

I'm sure some of you will ask for sources, but to be honest there aren't really any to share. I just grabbed the Open Video Player and configured it completely via flashvars, so I have not even got a FLA I could show you. As for the video settings I used - sorry but I can't honestly remember. All I recall is that I downsized the clip a bit so the resolution is not the same as in the original source footage, and no other fancy settings were used. As I said I simply encoded using the Flash Media Encoder.
Enjoy, and let me know what you think.

Accessing the NetConnection Object in FLVPlayback

Fri, 14 Aug 2009 11:13:00 +0100

There are situations where it is necessary to call a server side method on FMS. Some CDNs, for example Limelight, used to or maybe still do require you to call the FCSubscribe method in order to request a live stream. This send a signals to the Edge server to pull the live stream from the Origin server if it is not already being delivered to that Edge. While this delivery method and stream setup routine is being phased out across most CDNs I thought it may be useful to post a (slightly hackish) workaround to make this setup work with the FLVPlayback component.
The problem with the FLVPlayback component is that there is no obvious, simple way to obtain a reference to the NetConnection Object it uses under the hood. Sure, the ncMgr.getNetConnection let's you grab it but only once the connection is established, and while you can implement a custom NCManager class, this is not trivial and after all a NetConnection is being maintained already by the component, so why reinvent the wheel?

The following code is clearly not something I am proud of, but it worked at the time when I needed it. It was used to get a live stream working with the FLVPlayback component streaming from Limelight about a year or two ago.

// listen to player events and kill manual connection once we're streaming player.addEventListener("playing", playListener); player.addEventListener("stateChange", stateListener); player.addEventListener("ready", readyListener); /* this is the hack: check once every frame if the NC has been defined inside the FLVPlayback component */ this.onEnterFrame = function() { if (player.ncMgr.getNetConnection() != undefined) { this.onEnterFrame = null; delete this.onEnterFrame; trace("got NC"); //subscribe(streamName); } } var nc:NetConnection; var serverName:String = "server.llnwd.net"; var appName:String = "account_name/_definst_"; var streamName:String = "live"; var source_Str = "rtmp://" + serverName + "/" + appName + "/" + streamName; // start up by setting the contentPath (now called source in newer versions of the component) player.contentPath = source_Str; function subscribe(name:String) { nc = player.ncMgr.getNetConnection(); nc.onFCSubscribe = function(info:Object) { trace("onFCSubscribe: " + info.code); clearInterval(int_id); if (info.code == "NetStream.Play.StreamNotFound") { // handle error, retry after a few secs or similar } else if (info.code == "NetStream.Play.Start") { // we're successfully subscribed } else { // handle error } }; // not used right now nc.onFCUnsubscribe = function(info:Object) { } trace("subscribing to " + name); nc.call("FCSubscribe",null,name); } // can be used to unsubscribe from stream function unsubscribe(name:String) { nc.call("FCUnsubscribe",null,name); } Hopefully this is helpful to someone.

Deep Thoughts on Silverlight

Tue, 28 Jul 2009 22:07:00 +0100

Jan just posted a great article about Silverlight, Flash and RIAs in general. As expected, Jan approaches the topic from a video angle, but comes to some of the same conclusions as many of us here in the Flash camp: "If Microsoft dropped Silverlight tomorrow, most web site owners and 'Netizens' wouldn't even notice, or care if they did."

And of course I'd like to give Jan a hug for quotes such as "Flash caught on because it provided design functionality that HTML couldn't match and solved problems that no other technology could. It succeeded because website designers, developers and owners wanted it, not because Adobe needed it."

Very true. And that also means that Adobe gave those designers, developers and content owners the right tools for the job at the right time. Let's not underestimate the foresight Adobe had back in 2000 or so - long before anyone ever heard of Youtube and the like - when the foundations were laid to make Flash the de facto video standard on the web. While I doubt they envisaged quite this level of success they were certainly aiming for it. Has Adobe been able to leverage the success of Flash video and turn it into a money spinner for themselves? Not really. But have they managed to secure the future of the Flash platform for some time to come? Definitely.

It's onwards and upwards from here for Flash video. Adobe is undoubtedly busy cooking new and clever features in the labs, and anyone who has seen or watched the RTMFP sneak peaks at MAX knows that this technology could be another game changer. I can't wait to see more. There are many good ideas still to be had.

PS: I recommend you read Jan's full article, including the first part which focuses more on UGC and H.264.

Dynamic Bitrate Streaming for Kiwanis.org

Mon, 06 Jul 2009 17:30:00 +0100

I was recently tasked with upgrading the video player for the Kiwanis Convention website. The event itself has now passed but the videos are still online, you can check them here.

The client already had a video player in place but wanted to offer a better experience to users on slower connections as some users reported problems viewing the single file, high bandwidth versions without constant rebuffering.
I upgraded the existing FLVPlayback component to the latest version 2.5 and deployed a bunch of SMIL based XML files, one for each clip, which in turn pointed to the different videos.Here's an example of the SMIL format I used: I saved the SMIL files with an XML extension, and I recommend you do the same unless you know that the web server serving up those files knows how to process .smil files. Mine didn't, so I would have had to set up a new MIME type for .smil. But since I didn't know what the client's server would support I opted for .xml and played it safe.

Video playback has been greatly improved and stream switching is now handled behind the scenes in a seamless fashion in case end user bandwidth fluctuates during playback. We settled for three bitrates in the end; I did consider offering four bitrates but it appeared that the player switched a bit too often for my liking in certain situations.

Here are the videos again.

Producing H.264 Video for Flash

Wed, 24 Jun 2009 17:25:00 +0100

My friend Jan has a great article on H.264 video production on his site. You can read the first part below, and catch the rest on his blog.

Introduction
As a producer of video on the web, you know that you're judged by the quality of your video. In this regard, many producers are considering converting from the venerable On2 VP6 codec to H.264. H.264 offers better visual quality than VP6, and the AAC audio codec offers much better quality than the MP3 codec paired with VP6. Starting with Adobe Flash Player 9 Update 3, you could play back files encoded in H.264/AAC formats. As of September 2008, the penetration of H.264/AAC-compatible players exceeded 89% in all Internet-connected PCs. No wonder they're switching over.

This article first discusses the issues involved in such a changeover, including the potential requirement for royalties. I then describe the H.264-specific encoding parameters offered by most encoding programs. Finally, I cover how you can produce H.264 video with Adobe Media Encoder CS4 and Adobe Flash Media Encoding Server 3.5.What is H.264?

H.264 is a video compression standard known as MPEG-4 Part 10, or MPEG-4 AVC (for "advanced video coding"). It's a joint standard promulgated by the ITU-T Video Coding Experts Group (VCEG) and the ISO/IEC Moving Picture Experts Group (MPEG).

H.264's audio sidekick is AAC (advanced audio coding), which is designated MPEG-4 Part 3. Both H.264 and AAC are technically MPEG-4 codecs--though it's more accurate to call them by their specific names--and compatible bitstreams should conform to the requirements of Part 14 of the MPEG-4 spec.

According to Part 14, MPEG-4 files containing both audio and video, including those with H.264/AAC, should use the .mp4 extension, while audio-only files should use .m4a and video-only files should use .m4v. Different vendors have adopted a range of extensions that are recognized by their proprietary players, such as Apple with .m4p for files using FairPlay Digital Rights Management and .m4r for iPhone ringtones. (Mobile phones use the .3gp and .3g2 extensions, though I don't discuss producing for mobile phones in this article.)

Like MPEG-2, H.264 uses three types of frames, meaning that each group of pictures (GOP) is comprised of I-, B-, and P-frames, with I-frames like the DCT-based compression used in DV and B- and P-frames referencing redundancies in other frames to increase compression. I'll cover much more on this later in this article.

Like most video coding standards, H.264 actually standardizes only the "central decoder...such that every decoder conforming to the standard will produce similar output when given an encoded bitstream that conforms to the constraints of the standard," according to Overview of the H.264/AVC Video Coding Standard published in IEEE Transactions on Circuits and Systems for Video Technology (ITCSVT). Basically, this means that there's no standardized H.264 encoder. In fact, H.264 encoding vendors can utilize a range of different techniques to optimize video quality, so long as the bitstream plays on the target player. This is one of the key reasons that H.264 encoding interfaces vary so significantly among the various tools.

Will there be royalties? Find out by checking out the second part of this article on Jan's blog.

Strobe Media Framework Presentation

Sun, 07 Jun 2009 22:35:00 +0100

Sumner Paine, Product Manager of the new Strobe media framework, recently presented on this very topic to the FMS User Group. You can see the recording here.

If you haven't heard about Strobe yet, the official summary is: "Strobe provides new delivery and monetization options for video distribution. Anyone can develop modules that plug into Strobe media players and enable things like advertising insertion, content delivery and syndication, micropayments, viewer authentication, transaction handling, and business model controls. With an open framework, the future of web video monetization can be developed collaboratively with lower costs and faster turnaround."

Watch the recording here.

H.264 - Critical Links and Information

Wed, 03 Jun 2009 17:04:00 +0100

My friend Jan was recently asked by a client for a list of H.264-related references. And Jan figured that if these references are worthwhile to his client, perhaps they might be worthwhile for you, so here they are. For much more great content around all things streaming check out Jan's Streaminglearningcenter.com.

General H.264

Wikipedia - it all starts with Wikipedia, but you probably knew that. Here you can find all you need to know about profiles, levels and entropy encoding (oh, my!).

The Future's So Bright: H.264 Year in Review. Before you recommend H.264 to a client, or for internal use, you need to know that H.264 comes with some baggage, in the form of royalties (yes, royalties). In fact, depending upon how you're currently deploying H.264 encoded video, you might already have triggered a royalty obligation. Read all about it here, as well as why H.264 adaption has been relatively slow among major broadcasters and corporations.

MPEG-LA AVC/H.264 FAQ. Hmmn. Royalties, you say? Yup, here's the FAQ, with a link to a summary of license terms in PDF format.

Scalable Video Coding - the Future of Video Delivery? H.264 Scalable Video Coding (SVC) could be the technology of choice for three-screen producers (mobile, living room, computer). Never heard of it? Well, get a quick brain dump here.

Which codec is hardest to play back; VC-1, H.264 or VP6. Certain competitors of H.264 have long claimed that it's harder to play back H.264 streams on low power computers than other technologies. You can see the results of comparison results supervised by Microsoft and Adobe, here.

Producing H.264 and H.264 Codec Quality

The HD Showdown: Codec Vendors Battle it Out for Supreme Quality. How does H.264 quality compare to VP6 and VC-1? Well, Microsoft encoded the VC-1 files, and On2 the VP6, and I produced the H.264 files myself, then compared the three. Check out the results in this article.

Presentations from StreamingMedia East, 2009. H.264 quality varies by codec vendor. In the Encoding_H264-SME-2009.PDF presentation, you can see comparison samples for Apple, Dicas and Main Concept. Also lots of valuable information about producing and configuring H.264 video, including illustrated instructions for producing H.264 video with Adobe Media Encoder, Apple Compressor, Sorenson Squeeze and Telestream Episode Pro.

Squeeze 5.1's H.264 Encoding Quality Dramatically Improved. I've been dogging Sorenson about the quality of their H.264 video since Squeeze 5.0 was released. Well, they fixed it, and you can see full resolution comparisons with Apple, Rhozet Carbon Coder and Adobe Media Encoder in this article.

YouTube does 720P HD using H.264. Wanna see how YouTube does H.264 at 1280x720? It's big and bold and beautiful. OK, maybe there's an issue or two. Read all about it here.

H.264 and Flash

Encoding Options for H.264 Video. Here's an article that I wrote for Adobe (shameless name-dropper that I am) which discusses how to configure H.264 video for Flash and general deployment. If you're wondering what data rate to use, or whether CABAC produces better quality than CAVLC (and how much harder the files are to decode), this article is for you.

Kaourantin.net. The seminal article on Flash and H.264 written by Tinic Uro, an Adobe Engineer on the Flash team. I love the title - "what just happened to video on the web," and it was written on the day that Adobe announced H.264 support in Flash.

Adobe.com - Supported Technologies - H.264. This article defines the profiles and levels supported by the "Adobe Flash Platform" technologies. Pretty much says what Tinic Uro says, but straight from the mouth of Adobe.

H.264 and Silverlight

Commentary: Microsoft Should Embrace H.264 Video - Streamingmedia.com. I'm sure that Microsoft adapted H.264 for Silverlight for their own reasons, but I can't resist patting myself on the back for recommending it months before they did, and while they were actively denying that they would adapt H.264.

H.264 and AAC Support Coming in Silverlight.- Ben Waggoner's Tinic Uro moment, discussing why Microsoft adapted H.264 and why. Click here to see the types of H.264 files supported in the beta version of Silverlight 3, another blog post from Waggoner.

For more great content around all things 'streaming' check out Jan's Streaminglearningcenter.com.

Keep up to date on new blog posts: follow me on Twitter or subscribe to the RSS feed.

Adobe Media Player - R.I.P.

Fri, 24 Apr 2009 10:48:00 +0100

Adobe is to discontinue the content syndication through the Adobe Media Player (AMP), essentially laying the whole initiative to rest reports NewTeeVee.

Personally I'm not surprised. The shows that were available in AMP did not really appeal to me and the format of a desktop media player was also not what consumers seemed to want or indeed need - Joost anyone? The 'iTunes for video' concept simply did not catch on.
Strobe, the new media player framework that was recently announced, now appears to be taking center stage and is being pushed as the way forward when it comes to building media players (initially for the web but we all know how easy it is to turn a Flex based application into an AIR based client), and the coverage on NewTeeVee seems to suggest that even Adobe had their problems when building AMP, contributing to the birth of Strobe.

R.I.P. Adobe Media Player, I won't be missing you though.