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 :-)

Great news today amidst the Inauguration celebrations: Adobe is to publish the specifications for its (apparently patented) RTMP protocol. This protocol (the real-time messaging protocol) is designed for high-performance transmission of audio, video, and data between Adobe Flash Platform technologies, including Flash Media Server. Other server platforms such as Wowza and Red5 had in the also added support for RTMP and this announcement should make it somewhat easier for third parties to develop compatible technologies (if there are still any unanswered question about RTMP that is).

According to Adobe's Serge Jespers, the RTMP details will soon be published on Adobe.com. The full press release is here.

"With the RTMP specification, developers and companies will be able to provide users with optimized audio, video and data streaming, no matter what kind of device the user is on or where the content is coming from," said Adobe CTO Kevin Lynch. "Our ongoing commitment to openness is accelerating adoption of the Flash Platform by developers and resulting in a new generation of Web applications, content and video experiences that run reliably across operating systems and devices."

Understandably Adobe will not release details of the secure variants of RTMP such as RTMPE since it forms the backbone of some of the content protection measures in Flash Media Server.

Not my words but those of the Wall Street Journal and Lost Remote, talking about the MSNBC Inauguration video player. They are right though, this player is pretty cool and the features can honestly be described as innovative: the Inauguration site allows users to highlight parts of the closed captioning transcript next to the video and then embed just the selected pieces on other sites, playing only the parts one has selected.

The technology used to deliver? No, not Silverlight but Flash (did you really think I'd blog this if it wasn't? :-)

It's a bit of a shame though that there' are a bunch teething problems with this player - runtime errors whizzing past when you access the player using a debug version of Flash, and the embed didn't work well for me either since it played the whole video and not the part I highlighted, and at times I got even served the mobile version of the site!? Could someone give the guys at MSNBC some ActionScript training please ;-) Ok, I am kidding, credit where credit is due and I am sure they will get it all fixed in time.

Please find below the presentation that Matthew Kaufman of Adobe gave at MAX North America. It covers the new RTMFP protocol and gives some detailed insights into its capabilities as well as possible future features including the much talked about application-level multicast.

Keep your eyes open for the full video of the presentation on Adobe TV (I am not sure if it will be published there or not, but the video roadmap session is there already).

Adobe has just announced that Stratus is now publicly available for use by developers as a beta service. This is the long awaited missing link that will allow developers to take advantage of the new UDP based RTMFP protocol in Flash Player 10 and AIR 1.5. Why is this important? Well with RTMFP and Stratus, data can now be sent directly client to client allowing for highly cost-effective real-time communication.
In order to use RTMFP, Flash Player endpoints must connect to an RTMFP-capable server, such as the Adobe Stratus service. Stratus is a beta, hosted rendezvous service that aids establishing communications between Flash Player endpoints. Unlike Flash Media Server, Stratus does not support media relay, shared objects, scripting, etc. So by using Stratus, you can only develop applications where Flash Player endpoints are directly communicating with each other.

At MAX this year we also learned that a future (and yet unreleased) version of FMS will also support RTMFP and will be able to facilitate the same endpoint functionality as Stratus. But not only that: this future version of FMS can also use RTMFP in a client-server-client architecture, meaning that any traditional FMS based application can potentially make use of UD based, low latency communications. It does not have to be peer to peer setup... that I think is great news.

In the meantime you can sign up for a Stratus developer key and start playing.

A page and FAQ on Adobe Stratus is now up on Labs.

As you may have heard, Stratus is the name of an upcoming service that will allow Flash Player 10 and AIR 1.5 clients to connect directly to one another in a peer to peer mode and exchange data once a connection is established. The protocol used is the new RTMFP (real time media flow protocol) protocol and it runs over UDP, not TCP. The use of UDP has a positive effect on latency and will therefore make Flash Player's peer to peer features ideal for one to one communications and reduce bandwidth costs since the server is sidestepped. You can try the new features using this sample application (Player 10 required).

While the Stratus cloud service is necessary to connect clients in this way, there will also be an upcoming version of Flash Media Server that is capable of facilitating this connection. More information on this is available in this PDF file.

RTMFP is one of the most exiting developments for Flash Player in recent times and it will add major new capabilities to the platform. There are plans to develop RTMFP further, and I recommend you attend the Sneak Peak sessions at Adobe MAX Milan next week where Adobe may showcase application level multi-cast over RTMFP. As outlined by Matthew Kaufman at MAX North America, the RTMFP protocol could evolve further and support one to many broadcasts, Group setups as well as Direct Routing.
Flash Player 10 will not enable swarming, multi-cast or broadcast quality live video at this time.

These are definitely exciting times to be a Flash Platform developer.

Wow, it even appears to convert some users from Windows to Linux if you believe the comments in this article.
You can grab the 64bit Flash Player 10 for Linux on labs.

As you may know I am spending the main part of this week at Flash on the Beach in Brighton. If you don't know what Flash on the Beach is, it's the biggest Flash (and Flex, AIR etc) conference in the UK, if not Europe. It's also the best conference of the whole year in my calendar. I presented my session on monday right after the keynote so I am now free to enjoy the conference fully. While attending some of the sessions I gathered a few interesting bits of information, some of which may not have been public knowledge before.

In case you are trying to find the debugger version of Flash Player 10 (like I was): you can get it here.

UPDATE
Now that Flash Player 10 is officially out you can download the debug version from http://www.adobe.com/support/flashplayer/downloads.html#fp10

*** UPDATE 10th Octover 2008 *** The bug has now been withdrawn from the SWFObject project since we are no longer convinced that SWFObject is the culprit here. In fact I'm having a hard time reproducing this problem now in anything but one application which uses the old Macromedia communication framework. With that particular app I can reproduce the problem regardless of browser and OS, whereas before the problem only surfaced for me on IE on Windows. I will post updated here as I find them. *** END UPDATE ***

I've just managed to iron out a nasty bug in one of my FMS apps and this issue will likely affect other applications.
One of my clients noticed that some users would show up multiple times in a userlist of one of my applications. The userlist was tied to a SharedObject and users were removed from this SharedObject as they logged off. I noticed that the issue only surfaces in Internet Explorer 6 and 7, regardless of the minor Flash Player version used.
Moreover (and this was the hard bit to figure out) the issue seemed to surface only on those pages which used SWFObject 2 or SWFObject 2.1 to embed the SWF. Any pages using a previous version of SWFObject (in particular I was using version 1.5) the problem did not occur.

My conclusion is therefore that the problem somehow lies with SWFObject and how it interacts with Internet Explorer. For some reason the onDisconnect event is not invoked on FMS (I was using FMS 2 in this particular app) when my SWF was embedded with SWFObject 2.0 or above and I have now rolled back to SWFObject 1.5. Hope this helps someone as it may easily have you pulling your hair out.

An updated version of the Flash Player 10 Beta has been posted on http://labs.adobe.com/technologies/flashplayer10/releasenotes.htmlAdobe Labs. Some bugs have been fixed and new features been http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#features>added including limited fullscreen keyboard access (allows you to play games or interact with a video player while in fullscreen mode), support for Ubuntu and support the Video4Linux v2 camera API, amongst other things.

You can get Player 10 Beta on labs.adobe.com.

I've just stumbled over this in the release notes for player 10 Beta:

File Reference runtime access -- Bring users into the experience by letting them load files into your RIA. You can work with the content at runtime and even save it back when you are done through the browse dialog box. Files can be accessed as a byteArray or text using a convenient API in ActionScript without round-tripping to the server. You no longer have to know a server language or have access to a server to load or save files at runtime.

That's yet more big news. Saving actual files locally? Load files into the app without going through a server first? WOW! Combine this with video downloads and P2P...

Hank Williams even thinks that this technology could kill CDNs. I'm not sure if I agree with that totally, but it will have an impact no doubt. It remains to be seen how restrictive or open this new API really is. But we will have fun over the coming months, that much is clear.

Oh, and it looks like I was right about the multi bitrate support too. :-)

Good morning coders, and what a morning it is. There's some huge, huge, huuuge news. Did I mention how huge this is?

Flash Player 10 Beta has just dropped on Labs and while the most hyped features center around 3D support and custom filters (amongst other things), there's also a goodiebag full of toys for the audio/video crowd.
How do you fancy some UDP? Peer to peer? Speex audio codec support (finally!)?

Let's dig a little deeper. The new rich media features in Flash Player 10 beta cannot be leveraged until the next version of Flash Media Server ships (this is likely to be a dot release to go hand in hand with the Player 10 release). However you can apply to take part in the FMS prerelease program and test these features before they are publicly released.

The next version of FMS and Player 10 will introduce a new protocol, RTMFP, which stands for Real Time Messaging Flow Protocol. This is a low latency, UDP based protocol that is based on Amicima's MFP protocol. Amicima was aquired by Adobe in 2006.

It sounds likely that FMS will act like a switchboard to connect various Flash clients into an optional peer to peer mode, offering high quality, low latency audio and video communications, and thereby sidestepping any bandwidth flowing through the server itself. Did I mention higher quality and lower latency? Think Skype inside a Flash application. Oh yes, I'll take two of those please.

In addition to the new protocol there's a new audio codec, Speex, to go with it. And what a great choice this codec is since Speex is open-source, as well as patent and royalty-free. It will be a revelation compared to Nellymoser, the only audio encoder that's currently present in the Flash Player.

There are tons of other exciting new features in Player 10 (enhanced text support - yeah), you can check a list here.

Oh and btw, Player 10, codenamed Astro, is really making some noise with its new sound features.

Rock on.

Interesting. Apart from the cool 360 degree video demo I blogged about earlier today, there also seem to be new features on the horizon for Flash Player and FMS when it comes to support for multiple bitrates and seamless switching between them depending on network conditions.

Kevin Towes presented on FMS at NAB recently and towards the end of his talk showed some sneak peaks of possibly upcoming new features in Flash and FMS. The experience he demoed shows an absolutely seamless switching capability between video feeds, or between multiple bitrates inside one file. It is not clear if it is the former or the latter, but in any case it sounds like that this is coming and it will make moving between bitrates of a single clip much easier and smoother. So smooth that you can't even hear a break in the audio.

Unfortunately the direct link to Kevin's talk does not seem to work, but if you go to http://tv.adobe.com and search for 'Kevin Towes' you will find the clip. It's the first result that comes up in the search and the sneak peak is towards the end of the presentation.

I'm not sure about it - but they say they did. In their recent FMS3 white paper on page 8 there's a reference to "the Adobe patented, RTMP over Transmission Control Protocol". I'm not sure if this was common knowledge but as far as I remember there was no known patent in existence around RTMP - but it certainly looks like there is now. A quick Google patent search brough up this result.
While RTMP has not been patented explicitly in this patent, something that sounds even wider reaching has (at least to my limited experience), namely a "Method and system for facilitating communications between an interactive multimedia client and an interactive multimedia communication server".

While I don't know if this particular patent is the one cited in the white paper but it was the only one I could find that appears applicable. It is US patent number 7246356, filed on Jan 29, 2003 (that's not too long after FCS was released and way before FMS2) and issued on Jul 17, 2007.
The inventors list is a who's who of Flash and FMS and includes Slavik Lozben, Pritham Shetty, Jonathan Gay, Stephen Cheng and Bradley Edelman.

I'm not sure what implications (if any) this patent may have for the likes of Red5, Wowza and other RTMP servers but it certainly appears that Adobe wants to protect their intellectual property at least on paper and 'just in case'.

Tinic Uro has posted a lot of information on the new file extensions that will be used by Flash video, given the fact that H.264 encoded content will become more and more popular and important over the coming months.
The primary reason for the move away from .flv for H.264 encoded content appears to be compatibility: Adobe want to ensure that a file with a a certain extension is compatible with Flash. The primary extension for H.264 compatible video in Flash will be .f4v. Other file formats include .f4p for protected media, .f4a for audio files and .f4b for audio books. You may still use .flv for these files (the Flash Player will not look at the extension anyway) but I guess this is discouraged. If you run your own web server then I recommend you add the necessary MIME types now (they are listed on Tinic's site) or ask your hosting provider to do this. I remember many issues a few years back when .flv became popular as web servers did not know how to serve that format in a way that browsers could understand.

More information can be found on Tinic's blog.

As you must have heard by now, Adobe have announced the upcoming support for H.264 video in the Flash Player. I guess On2 kind of gave the game away when they shifted their focus somewhat into the direction of H.264, yet my jaw is still firmly on the floor - I didn't think this would come around so quickly.
The bottom line: a huge step forward for web video. The Flash Player will incorporate what is arguably the most versatile and most widely adopted video codec around (it's used for much more than just web video), and it's an open standard at that with a huge eco system of encoders and tools to boot. Let it sink in and expect some big waves from this. You will be able to test this out via progressive download (I know I will) once Flash Player Beta Update 3 hits the streets later today on labs. Both Flash Media Server and Flash Media Encoder will support the codec in upcoming versions.
Tinic Uro has the most comprehensive set of information on his blog. Go check it out.

More coverage here.