Today I was working on a Flex 3 application which I now want to compile using the Flex 4 SDK. One of the warnings that cropped up in the Flash Builder Problems panel was the following message:
3608: 'getStyleDeclaration' has been deprecated since 4.0. Please use 'IStyleManager2.getStyleDeclaration on a style manager instance'.

The line in question was the following which applies a global theme color after a color value has been loaded from a remote data source::

It took me some time to figure out what the heck the 'use IStyleManager2.getStyleDeclaration on a style manager instance' actually meant... it was by no means a straight forward warning. After some Googling and trial and error I came up with this which seems to do the job:

I'm not sure if this is the correct and/or best way to achieve the same thing but it appears to work which generally is good enough for my requirements :-)
Hope this helps someone, please leave feedback and corrections where applicable.

John Harding, Software Engineer at Google, has posted a lengthy article about the pros and cons of Flash video and HTML5 video support in today's browsers. It's fair to say that the post is in essence a major thumbs up to the Flash Platform. The author points out that video on the web today is much more than a simple video tag pointed at a file, but involves other considerations such as widely supported codecs, secure delivery mechanisms where required by content owners, two way video and audio for recording live via webcam as well as immersive fullscreen options.
All this is of course supported today via the Flash Player but not via HTML5, and whilst we all agree that it'd be very nice not to have to wrap a video into a SWF wrapper we must also face the reality that in many cases a simple click and play experience just doesn't cut it anymore. HTML5's video capabilities could have given Flash a run for its money about 10 years ago when Flash first started building momentum for online video delivery, but they are no match for the type of features that web users today are accustomed to and demand as standard.

Sure, of course I am biased, but I am also smart enough to know when I'm beating a dead horse, and Flash definitely is not one of those. Whilst new technologies such as HTML5 are most welcome, especially when they make a developer's life easier they also need to make sure that they don't over-promise and under-deliver. The amount of hype some companies have been able to generate around HTML5 is almost unreal, yet the follow-up on that hype remains to be seen. In the meantime I'll get back to work to make bling with Flash, clients are waiting and the biggest app store of all is still the web ;-)

How did I get here? Sorry - here's the YouTube blog post again.

Jan Ozer was quick on the mark to deliver a side-by-side comparison of video encoded with VP8 (the codec which Google open sourced as recently as two days ago) and H.264, the de-facto codec standard for web video and beyond.
You can check out Jan's tests here on streamingmedia.com but in summary it is safe to say that any differences in quality are negligible. What remains to be seen is of course how the same codecs perform across a range of bitrates; maybe VP8 does excel once you throw higher resolution, higher bitrate content at it? Or maybe it will distantiate itself at low bitrates?

But regardless, the mere fact that VP8 is open source now and that it is a serious contender in the codec wars that rage around the web in the past few months is a great thing. Remember that H.264 is a patent encumbered format with a patent pool overseen by an organisation called MPEG-LA, and license fees are payable for certain types of usage. It is the uncertainty about these fees and their possible future rise that give organisations like Mozilla cause for concern - and they are not alone. By open sourcing VP8 Google is obviously prepared to call the bluff of anyone who may claim to hold patents on which the VP8 codec may infringe. Now that the sources are open for anyone to see it is now possible to inspect them, and quite likely sue Google for patent infringement. Of course we don't know yet if that's the case, but I truly hope that this big questionmark will once and for all be cleared up by a court. Hopefully VP8 is either free of patent infringements or Google can strike agreements that shield anyone from being sued if they use the codec. No doubt the web would be a better place if we had a free to use, patent free, high performant codec available for everyone to use with no strings attached. Google is definitely up for it and saying: "Bring it on, whoever you are."

I'm sure Adobe is totally loving this, for various reasons :-)

Today's definitely a big day. The Google I/O keynote is about to start but some details of what will be announced are already public on the web. In particular it is clear - as was expected - that Google has released the source code for the VP8 video codec. VP8 of course is a supposedly high quality video codec which Google now owns after its acquisition of On2.

Not stopping there, Google set up a new media file format called WebM. You heard it here first :-) I can tell you you will hear a lot more about this very soon, and for a long time to come.

So what is WebM? According to Google it is 'an open, royalty-free media file format designed for the web. WebM files consist of video streams compressed with the VP8 video codec and audio streams compressed with the Vorbis audio codec. The WebM file structure is based on the Matroska media container.' Wow. That's pretty awesome and could definitely a game changer.
WebM is also royalty free. As they explain: "Some video codecs require content distributors and manufacturers to pay patent royalties to use the intellectual property within the codec. WebM and the codecs it supports (VP8 video and Vorbis audio) require no royalty payments of any kind. You can do whatever you want with the WebM code without owing money to anybody. " Well, I think one should add that we will need to wait and see about possible patent trolls coming out of the woodwork once they had a look over the VP8 source code. At least Google is well used to fighting attacks like this so let's see how this plays out. So to sum up, WebM is 100% free (at least initially), and open-sourced under a BSD-style license.

Also interesting is the WebM supporters page. There are many well known companies and brands listed including FireFox, Opera, Android, Chrome and - wait for it - Adobe Flash Player. Wowzers. Maybe we'll hear more about this at the keynote? VP8 in Flash Player would be sweet. The keynote starts in 10 minutes (from the time I type this). One logo notably missing from the supporters page is that of Apple. But that does not mean anyone is missing them.

Adobe have made some announcements at this week's Streaming Media East Conference in New York and streamingmedia.com has some great coverage on that.

The two main topics are the announcement that Flash Access 2.0, Adobe's new flavour of DRM for Flash video, is now available. Previously known as Adobe Flash Media Rights Management Server, Flash Access 2.0 will enable publishers to encrypt content at source and deliver it securely to the end user. This is different to simply using RTMPE for encrypted streaming as not only the transmission will be encrypted but the actual content will be as well. Previously, with Adobe Flash Media Rights Management Server, this technique was only supported in AIR, Adobe's desktop runtime. But with Flash Player 10.1 it will also be supported in the browser based Player, and there are a bunch of new AS3 APIs to make this happen.

Secondly is HTTP streaming. This is also a new 10.1 feature and will allow transmission of video content over HTTP, with the difference that it is no longer a simple progressive download but will also support full seeking, live broadcasts and multi-bitrate switching. A real alternative to RTMP based streaming basically. What's more, the HTTP streaming module for on-demand streaming over standard HTTP servers will likely be free, whilst the live module looks likely to be a paid product.

As mentioned, more details are to be had in Tim's article on Flash Access and the Player roadmap as well as Troy's piece on Flash Access and HTTP Streaming.

Here's a great interview with Kevin Lynch from yesterday's Web 2.0 Expo. He talks a lot of sense, but also gets misquoted in a lot of so-called tech blogs. So instead of consuming the spin-everything-into-an-HTML5-versus-Flash posts and FUD-injected written articles I suggest you just watch this video and hear things from the horse's mouth. Good stuff Kevin.

I've just sent the following to the EU Dev Support at Apple.

==============================

Dear Apple,
As a developer who has successfully used Adobe Flash CS5 to build, submit and publish iPhone applications via the App Store I am unable to agree to the new Updated Program License Agreement you wish to impose on me.

Section 3.3.1 of the agreement states:
"Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited)."

Since my application has originally been written in ActionScript it is now in violation of these terms. This brings up two questions:

I got to be honest, I was gearing up for a massive rant on the latest PR effort by Apple in which Steve Jobs is trying to defend the company's ridiculous anti-Flash stance. But as it turns out I'm far too slow and some of my friends and colleagues have already said what needs to be said and I therefore would like to simply point you to a few of my favourite posts on the subject.

Maybe - just maybe - Adobe will be delivering on its promise of Flash on mobile this time. If videos such as the one below are anything to go by then now would be a good time to get excited - I know I am. Whether you like Flash or not, it is an integral thread of today's web's fabric and those platforms that try to exclude it are missing out on some great experiences.

I'll be ordering my HTC Desire later this month when I'll be saying: Bye bye iPhone and walled garden OS, hello Android.

Thanks to Jens for the video.

I've put a question mark there since this story currently does not cite any named sources, but NewTeeVee certainly seems convinced that Google will open source the VP8 codec, and will announce this at their upcoming Google I/O conference next month. The VP8 codec, developed by On2 which Google recently acquired, is a high quality video codec which supersedes VP6 (one of the most popular Flash codecs alongside H.264) as well as VP7 (used by Skype).

According to NewTeeVee, the aim of this exercise is to equip HTML5 with a decent and open video codec since the HTML5 specs make no recommendations for a specific codec and the playback compatibility of specific video codecs varies greatly between those browsers which support the HTML5 draft specs. The biggest hurdle right now being the inconsistent support of Ogg Theora, a codec which - whilst 'open' - many deem inferior to industry standards such as H.264 and VP6, as well as H.264 which Mozilla FireFox does not and most likely will never support.

Some new materials have just surfaced on the Flash Media List, they include a presentation on RTMFP by Matthew Kaufman. Matthew gave this presentation on Wednesday, March 24 2010 to the IETF. An audio recording is available for download via FTP here (the RTMFP part starts about 1 hour into the recording).

Interestingly, the presentation also contains an IPR disclosure which in turn contains a mention to 'unpublished pending patent applications'. Matthew noted that these applications are 'are where all the interesting stuff is, of course.' It's clear that Adobe is protecting its intellectual property around RTMFP.

Check out the slides by accessing the full article here (sorry about the Flash runtime error caused by Sideshare's player...).

Have noticed that when viewed in Firefox 3.6 some SWF files seem to mysteriously resize themselves or show a focus border when clicked on. At first I could not figure out what was happening when my fullscreen 100%x100% SWF suddenly forced scrollbars to appear in the browser once it received focus. It turned out that this is due to the fact that Firefox 3.6 now draws a 1 pixel 'focus' border around the Flash content which is very annoying. The same happens on Java Applets too.
Luckily there is a fairly easy solution to this, and itinvoves a bit of CSS. Simply add this to your page's stylesheet:

Problem solved.

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.

As you may already know, the Mobile World Congress kicked off today in Barcelona and it did not take long for the first announcements to hit the interwebs. Adobe has of course a large presence at MWC and today announced support for Flash Player as well as Adobe AIR on Android devices. While we have seen some demos of Flash running on Android already, support for the AIR runtime gives developers yet another option for deployment on mobile devices, besides the traditional Flash content for (mobile) web browsers that is going to hit mobile screen sometime in the first half of 2010. Adobe states that 19 of the top 20 phone OEMs are committed to delivering Flash and expects more than half of all smartphones to ship with Flash Player by the end of 2012. 19 out of 20... can you guess the missing one?

A picture says more than a thousand words (although these are very wise words).

Amongst all the noise that is currently being emitted after the jesusiPad 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."

Adobe have just announced the immediate availability of the version 2 of Stratus, an update to the existing Peer 2 Peer rendezvous service that was launched in 2008.

In Adobe's words: "Adobe Stratus 2 enables peer assisted networking using the Real Time Media Flow Protocol (RTMFP) within the Adobe Flash Platform. The most important features of RTMFP include low latency, end-to-end peering capability, security and scalability. These properties make RTMFP especially well suited for developing real-time collaboration applications by not only providing superior user experience but also reducing cost for operators."

While this sounds like the same capabilities that the previous version of Stratus offered it contains some significant updates, the main one being support for RTMFP Groups.

The title really says it all: Fabio's session titled Encoding Best Practices For H.264 Video Using Flash is - amongst many others - now available on Adobe TV.

I've not had a chance to watch it yet but feel free to leave comments below if you have. I'll definitely put it on my ever-growing MAX catchup list.

There has been a bit of confusion around which one of Adobe's collaborative platforms offers or will offer certain features. In particular many people have asked if a developer always needs to rely on a hosted service such as Stratus or Lifecycle Collaboration Service (aka AFCS aka Cocomo) when wanting to use the new RTMFP protocol which will deliver (partly is delivering already) new and exciting features to the Flash Player.

To clear thing up, Kevin Towes, FMS Product Manager at Adobe, just posted the following information to the FlashMedia List:

STRATUS - this will always be ahead of the curve, providing a way to help us roll out new features that are in Flash player, before we can have a server offering. The service is and will remain as a free non-commercial service from Adobe. This service is not FMS, and has no ability for Server side scripting, or customization.

AFCS/LIVECYCLE COLLABORATION SERVICE - this will be a commercial option for customers interested in building a business that includes RTMFP. We introduced a pricing model, and it has support for the features found inside Stratus 1.0 (supporting Flash player 10.0). Key advantage with this service is the framework, which is an option for developers to get started, and leverage RTMFP to RTMP failover technology. You still will not have access to server side scripting, but there are lots of APIs in the framework to get you going. The goal for this service is to provide developers an option to bring this technology into your solution.

FLASH MEDIA SERVER - we have not announced any new version of FMS yet that will support RTMFP. We did hint yesterday that we'll be updating FMS3.5 to version 3.5.3 later this year to support the new FP 10.1 features - and in a future version after that release - FMS may be one of your options to host a local service to build your own P2P applications - including introductions, and supporting server side programming.

Thanks Kevin, I think this clears things up somewhat.

The time has finally come to lift the lid on this. As you've probably all heard by now, Adobe today announced a brand new feature for the upcoming Flash Professional CS5: Export as iPhone app. Insane! Essentially what this feature will allow you to do is a cross-compilation from SWF to Objective-C - the resulting app is a totally legit iPhone/iPod Touch app which can be submitted to the Apple app Store. In my case that process has already happened, and the app has been approved!

I will post more details about the development process when things have calmed down a little, but for now I'm super exited to announce the immediate availability of my first application for iPhone and iPod Touch: my good old Just Letters game.
I figured this Flash game of mine which stems back from around 2005 would make an ideal candidate for a touch screen device, and I think I haven't been completely wrong with that assumption. Not only is Just Letters one of the first games built in Flash to ever hit the App Store but I have a feeling it is the very first game that use Flash Media Server to provide the real-time features.

In celebration of the launch I am distributing 10 free voucher codes for the US App Store (sorry, the vouchers do not work on App Stores outside the US). The game normally retails for $0.99. Just leave a comment below and I will pick a random 10 later today (leave your email too!).

Please help me spread the word about this game by blogging about it, tweeting or getting your grandma to buy a copy. Don't forget to review and rate it on the App Store too. please point people to the following age when you link to the game: http://www.muchosmedia.com/justletters (muchosmedia is my company, the 'official' developer behind the game).
Last but not least, if you need the game's icon or some screenshots then you can grab a small zip (1MB) from here. It also contains the game description in text format.

Thanks for your support!

In what appears to be an on-purpose release of MAX related announcements ahead of the event which starts today in LA, Adobe have announced the latest version of Flash Player: version 10.1. Do not let yourself be fooled by the .1 release as this version is much more than just another point release, it is a huge upgrade to Flash and the entire platform, touching many parts and in particular mobile and media delivery. Justin Everett-Church has a great breakdown of all the new features.

Overview
I'm not quite sure where to start, but I'll have a try:
Flash Player 10.1 can be labeled as a 'real' fully featured Flash Player for mobile. It contains a lot of optimisations as well as new APIs that are directly aimed at breaking open the mobile device market for Flash - I think it's safe to say that the time for Flash on mobile has finally come.

Jens Loeffler has published a nice little overview on his blog about the differences and similarities between Flash Media Server and Flash Access 2.0 a far as content and DRM mechanisms are concerned.

You can find Jens's article here.

Adobe will soon be adding DRM capabilities directly to the Flash Player, a feature that was previously only available through Adobe AIR, Adobe's cross-platform desktop runtime. The new feature was announced at IBC in Amsterdam today.

This is a fairly significant addition to the Flash Platform. While I'm not a fan of DRM, I understand that some content owners are very keen to add (what they perceive as) protection to their assets, and Flash will soon be capable to tick that box. The technology works in a similar fashion to the way in which the Adobe Media Player used to handle content protection: a DRM server called Flash Access 2.0 - which was also announced at IBC and which is basically a renamed release of Adobe Flash Media Rights Management Server (I'm glad that I won't have to type that name again!) - will handle the signing and protection aspects, while Flash Player can soon deal with the decryption and content access mechanisms natively. As mentioned above, this was previously only an option if Adobe AIR was used to build the client. I guess these new features and the demise of Adobe Media Player shows that end users prefer to consume content right inside the browser, and are less keen to install and use yet another video player onto their desktop. Those who prefer to use AIR to deliver their content can still do so as the runtime will also support the content protection features which Flash Access 2.0 promises. Here's the full press release.

Adobe Flash Access 2.0 is planned for commercial availability in the first half of 2010.

There has been a bit of confusion around which one of Adobe's collaborative platforms offers or will offer certain features. In particular many people have asked if a developer always needs to rely on a hosted service such as Stratus or Lifecycle Collaboration Service (aka AFCS aka Cocomo) when wanting to use the new RTMFP protocol which will deliver (partly is delivering already) new and exciting features to the Flash Player.

To clear thing up, Kevin Towes, FMS Product Manager at Adobe, just posted the following information to the FlashMedia List:

STRATUS - this will always be ahead of the curve, providing a way to help us roll out new features that are in Flash player, before we can have a server offering. The service is and will remain as a free non-commercial service from Adobe. This service is not FMS, and has no ability for Server side scripting, or customization.

AFCS/LIVECYCLE COLLABORATION SERVICE - this will be a commercial option for customers interested in building a business that includes RTMFP. We introduced a pricing model, and it has support for the features found inside Stratus 1.0 (supporting Flash player 10.0). Key advantage with this service is the framework, which is an option for developers to get started, and leverage RTMFP to RTMP failover technology. You still will not have access to server side scripting, but there are lots of APIs in the framework to get you going. The goal for this service is to provide developers an option to bring this technology into your solution.

FLASH MEDIA SERVER - we have not announced any new version of FMS yet that will support RTMFP. We did hint yesterday that we'll be updating FMS3.5 to version 3.5.3 later this year to support the new FP 10.1 features - and in a future version after that release - FMS may be one of your options to host a local service to build your own P2P applications - including introductions, and supporting server side programming.

Thanks Kevin, I think this clears things up somewhat.

The following post has been sitting in my drafts folder for a while and I wasn't sure whether to publish or not. Today I decided I would, and it was after reading a very interesting article by Mike Slinn on InsideRIA. It talks about Adobe's lack of focus on its developer community, and how a shift in startegy may mean winning the RIA market for Adobe.

I'm always hesitant posting an article such as the one that follows as it will most likely be perceived as mainly negative by Adobe and its employees, many of which I know personally and rate very highly. I realise that there are people behind the software that this corporate behemoth churns out and it is for that reason that I'd like to say upfront that everything posted here has Adobe best interests in mind. I desperately want Adobe to succeed in the RIA market (and commonly they are doing a good job - but could do better...) and it is frustrating to see them making decisions that I think are not in their best long term interest.

One of my recent posts to the FlashMedia List seems to have struck a nerve when I asked if anyone there had tried out a Java application called JScrCap yet. According to its author, a developer can 'put this Java code on your web site as a Java applet and get browser-independent, platform-independent screen sharing solution with minimal installation efforts from end users'.

The release of the RTMP specs by Adobe yesterday has thrown up some questions on the nologies. And free Adobe tech support too - I suggest you FlashMedia List, and several people are asking themselves if it is a good idea to actually read them as doing so (or even simply downloading the specs) will mean that you agree to be bound to the RTMP license. In particular, the license includes a section about prohibited uses:

"Prohibited Uses
The rights and licenses granted by Adobe in the RTMP Specification, including those granted in the Patent License, are conditioned upon Your agreement to use the RTMP Specification for only streaming video, audio and/or data content and not to make, have made, use, sell, offer to sell, import or distribute: (i) any technology that intercepts streaming video, audio and/or data content for storage in any device or medium; or (ii) any technology that circumvents technological measures for the protection of audio, video and/or data content, including any of Adobe's secure RTMP measures. No right or license to any Adobe intellectual property is granted for such prohibited uses."

A long thread started on the list, and it was great to see not only community members participating but also several Adobe employees, including FMS engineers and even the product manager himself. Regardless of what you think of the RTMP license (I personally think it's a huge step in the right direction and underlines Adobe's commitment to removing barriers in this field) I think this level of engagement is rarely (ever?) seen by a multi-billion dollar company. Not only did Adobe engage, but they posted a wealth of information around the intricacies of RTMP/E/S security - many thanks to Kevin, Matthew, Asa, Jody and Brad (hope I didn't miss anyone) for regularly participating.

Further proof then (as if I didn't know) that the FlashMedia List is the place to be for the latest info on FMS, Flash video and its related technologies. And free Adobe tech support too - I suggest you subscribe right now :)
Once subscribed you can access the list archives here.

Today Adobe released the specification for Real Time Messaging Protocol (RMTP). The protocol documentation is available for Free, and describes how to use the messaging, chunking and handshake used by Flash Media Server. Adobe's secure protection measures are not exposed in this specification.

Adobe also announced a new product offering called the FMS Connector for C++ SDK, that is also available today for licensing. No details around the license terms have been made public yet, but anyone who is interested in the product can contact FMSOEMinquiries@adobe.com. The connector can be used to publish live audio, video and metadata into Flash Media Server.

I've noticed two separate presentations having been posted by separate authors, both covering the Peer-to-Peer features in Flash Player 10 in combination with Stratus.

The first, shorter video tutorial was authored by Tom Krcha of Adobe and guides you through building a simple P2P application leveraging Stratus. Watch it here.

The second presentation is an hour long session by Danny Patterson and goes into more depth than the previous tutorial. I haven't watched it in full but the part that I have seen looked very interesting and I definitely recommend you check it out.

It should be noted that Stratus is still in beta and detecting failed P2P connections can be a quite tricky. I would not recommend the P2P features for production use yet, instead you may want to rely on AFCS to handle the RTMP fallover for you.

Here's a story that is making the round on various tech news sites at the moment. On May 8th 2009, Adobe issued a takedown notice to SourceForge Inc, asking them to remove a project called rtmpdump from their website as - according to Adobe - it can be used to circumvent copyright protection measures. Even though the takedown notice doesn't mention it, rtmpdump can be used to record streamed content that is delivered via RTMP and (and this is the important part) RTMPE as well. The full wording of the notice can be found here. RTMPE is of course the encrypted flavour of RTMP, Adobe's real time messaging protocol (for which they apparently hold a patent).

As many of you will know, RTMP itself has been widely reverse engineered and documented, which made alternative RTMP servers such as Wowza and Red5 possible. Adobe have also recently announced that the RTMP specs will be made publicly available very soon, and so far I have heard of no action having ever been taken against anyone that implemented just RTMP. Quite clearly, the fuss is about RTMPE, not RTMP. It is the fact that rtmpdump can circumvent certain access controls that made Adobe react. By posing as a Flash Player, rtmpdump can connect to Flash Media Server and successfully pull and record an encrypted stream. In combination with the get_iplayer project rtmpdump made it possible to record all kinds of RTMP based content from sites such as channel4.com and the BBC iPlayer. The version of rtmpdump used within get_iplayer has now been removed and been replaced with a forked version called flvstreamer.

Admittedly it is not very often that Flash makes the news pages, but today is different. In what is obviously a key part of their Open Screen initiative, Adobe has just announced it has secured a deal to put Flash directly into many of the chips that go inside TVs and set-top boxes, essentially enabling any device that contains such a chip (there will be millions if not billions of them shipping over the next few years) to run Flash natively.

The article goes on to describe the use cases for such a TV set or STB: It will "create a new generation of connected entertainment services, including streaming video in high definition, and applications that can run in real time alongside video broadcasts, such as interactive news tickers, sport scores, quizzes and the weather."

Silverlight also gets a mention, but is described as having had "limited traction with developers and hardware manufacturers".

On the upside there is another hint which underlines Adobe's desire and efforts to get Flash Player onto the iPhone. All in all a great day for the Flash Platform as the ecosystem for developers has just widened considerably. Now let's hope that this story will make the 6 o'clock news too :-)