TheRealTimeWeb.com - FMS

FMS registerClass Example Added To github

Mon, 24 Sep 2012 10:15:00 +0100

Hi folks, apologies about the extended radio silence; I've been busy working on a new project which has taken up a lot of my time. The good news is that I am learning a ton of new stuff in the process which in turn should provide me lots to blog about. Expect posts about Rails, heroku, JavaScript, AWS and maybe even Flash ;-)

I've also just discovered a treasure trove of old projects and sample files and I've decided to offload many of them onto github. It would be a real shame to lose all this stuff, some of which is of course pretty useless whereas others may be useful to some folks. It'll be tricky to pick the right stuff as no doubt I will not be able to post everything I've got floating around...
So to make a start (and with the hope to keep this up) here's my first little Flash sample project. This one shows how to use registerClass to send custom typed ActionScript objects over RTMP between client and FMS server (sorry, AMS it is now...). I don't take full credit for it as I cannot remember if this was based on someone else's work or not... if it was you get in touch and I'll provide credit and link juice!

My github account can be found at https://github.com/stoem (not much there yet), and this particular repo is at https://github.com/stoem/FMS-registerClass.

Happy forking you forkers :-)

HLS Best Practices for AMS 5.0 with Sarge, Tuesday 28th August

Mon, 27 Aug 2012 08:17:00 +0100

Adobe Media Server User Group Meeting Tuesday, August 28th

RSVP: http://ams.groups.adobe.com/index.cfm?event=post.display&postid=43945

Topic: HLS Best Practices for AMS 5.0

Speaker: Sarge is a Senior Applications Engineer on Adobe's Video Solutions team. Formerly a FMS Technical Account Manager working with the top tier CDNs, Sarge has years of experience developing, deploying, and supporting Flash video solutions on FMS.

Agenda: Adobe added Apple's HTTP Live Streaming (HLS) to its technology stack with FMS 4.5 a few years ago as a continued investment delivering immersive on-demand and live video experiences over standard HTTP connections to Apple (iOS & MacOS) devices. This technology has been deployed at CDNs such as Akamai, Limelight, and Level 3, and used by broadcasters like the BBC for the London 2012 Olympics. Adobe updated its HLS workflows in Adobe Media Server 5 -- adding an offline packager, updated Just-in-Time encryption, and DRM support for iOS devices using and new Adobe Access 4 (AXS) technology. Come learn the recommended best practices for deploying HLS with AMS 5.0 from Sarge, Sr. Applications Engineer for Adobe Video Solutions.

Encode high quality video mezzanine MP4 files and deliver them in real-time simultaneously through RTMP, HDS, and HLS.
Configure HLS settings to optimize HTTP caching.
Add DRM to your iOS publishing workflows.

Sarge walks you through the changes to HLS in AMS 5.0, including:
Just in Time packaging (JITP) encryption
Offline packaging with the HLS Segmenter
iOS DRM

http://ams.groups.adobe.com/index.cfm?event=post.display&postid=43945

Adobe To Shut Down LCCS, Customers Badly Affected

Fri, 23 Mar 2012 08:34:00 +0100

After several recent announcement around Adobe's LiveCycle platform, it may not come as a surprise to some that the LiveCycle Collaboration Service (formerly Cocomo, formerly Flash Collaboration Service) will be shut down at the end of 2012. What may be a surprise however is the relatively short notice that Adobe is giving existing customers and a total lack of a migration path, leaving many people in a real tight spot.

Remember that LCCS is a hosted collaboration service, effectively cloud based, that allows developers to build real-time communications right into their Flex applications. The work that has gone into LCCS is impressive, and the platform offers a range of great features such as room provisioning APIs, live and audio and video communications (both over RTMFP and RTMP) and even screensharing capabilites (but let's not warm that topic up again...).

Put yourself into the shoes of an existing LCCS customer who has made a significant investment into the product - they are pretty much on their own going forward. It is no mean feat to engineer a similar service on top of FMS (a suggested migration path by the LCCS Product Manager), irrespective of the license fees that FMS would attract. Says one poster on the Adobe forum: "Companies may very well go out of business because of this decision. It's a pretty shameful act."

Make no mistake, FMS is not a straight forward alternative if you are used to LCCS, and suggesting so only confuses people. This is already evident in the forums where one user asks: "Will you be offering the code/installation instructions so that we can get this set up on FMS?"
Clearly the complexities of building a large scale collaborative application on top of FMS is not being grasped by some. There is no way to simply 'install' an LCCS app on FMS. Instead you are looking at weeks, more likely months, of engineering effort.

Some of my readers may know that a large part of my time is spent developing and maintaining Scribblar.com, a live collaboration app built on top of Flex and FMS. When LCCS first launched I carefully considered whether or not to port my product away from FMS to LCCS - I decided to stick with FMS. With hindsight that was the right decision - had I ported to LCCS then Adobe would just have introduced major costs and headaches at best, or killed my entire product at worst. What a mess.

I do need to add a few words about screensharing since forum users have asked about it. The screensaver add-on for Flash Player is not simply a feature of LCCS, it also requires Flash Player hooks to work. This means that even if Adobe was to open source LCCS (which they have stated already they will not do) you would not simply have screensharing features magically appear and work with FMS. No doubt this could be done with if Adobe wanted to make it happen, but I doubt very much that they have any interest in this.
Remember we have been asking for screensharing support for FMS for more than 10(!) years (remember my post about vendor lockout?). Yet FMS has stood still since its 1.0 launch as far as real-time communication features are concerned - instead time and effort was spent on the LCCS side to build an entire new platform plus component set, something we have not had in FMS since FCS 1.0.

I am gutted about the missed opportunities and I feel sorry for those businesses affected by the LCCS shutdown. If there is one positive takeaway from this then it should be the lesson of caveat emptor when building a business around a hosted service. If reliance on a single provider can make or break your product or service then it is time to make some backup plans.

Have you been affected by the LCCS shut down? What are your plans going forward? Please leave a comment below.

FMS/Wowza/Red5 Broadcaster App For Android

Thu, 12 Jan 2012 14:37:00 +0100

As one of the main contributors to the Red5 project, Paul Gregoire is a well known name in the community. Yesterday he posted a link to an AIR for Android app he built to the Flash Media List and I'm republishing his link here as I think many of you will find this app quite useful.

The Broadcaster Android app allows you to broadcast audio and video to an RTMP server such as Red5, and also works with FMS and Wowza. What's more, the app is free and will run on pretty much any Android device with Android 2.2 and up.

You can download the Broadcaster app from the Android Market.

But apart from being useful, the app also shows that AIR for Android can be quite versatile and allows you to easily publish what is essentially a Flex application to a mobile platform.

Hacking FCSubscribe Support Around OSMF

Tue, 20 Dec 2011 09:41:00 +0100

Recently I had the task of recreating a video player for a customer for which no source code was available. The player needed to support on demand and live streaming, so I opted for an OSMF based player - why reinvent the wheel?

Things went well until the time came to add the live streaming support. The chosen CDN uses the FCSubscribe method for live streaming. In case you don't know, FCSubscribe is a serverside method which the player needs to call in order to instruct the CDN to deliver the requested stream to the edge server that you are connected to in order to play the stream.
Some CDNs (including Akamai and Limelight) provide custom OSMF plugins for this task, and if your CDN does the same then you have nothing else to do apart from using their plugin and you are set. However some CDNs do not (yet) provide such plugins, and since the task of creating one is no mean feat (and it was certainly not part of the budget for the player I was working on), another solution had to be found.

I reached out to some of my friends in the community and Bob Wohl came up with an excellent and very simple trick: use a second NetConnection to connect to the edge server and invoke FCSubcribe ourself, then play the stream once it is available. Or in other ways, handle the FCSubscribe logic outside of OSMF. Right, I remember doing this a while back with the FLVPlayback component.

I created an ActionScript class for this purpose based on some code snippets from Bob and bingo, Bob's your uncle. (yeah sorry, couldn't resist!)

Find the code for the class as a gist below. Hope it helps someone and if it does don't thank me, thank Bob.

FMS Bandwidth Tester App Works Again

Tue, 13 Dec 2011 14:32:00 +0100

I've just fixed the (now ancient) FMS bandwidth tester. It's based on some pretty old code by Adobe engineer Pritham Shetty and wasn't working since I rebranded the blog - well now it's functional again and I plan to connect it to a new server soon.

The neat thing about this FMS app is that it checks bandwidth both to and from the server - this is very useful if you build RTC based apps that utilise things such as webcam video or live audio.
If right now the speed results seem low then that's probably due to the very old machine I'm using to host the app... Believe it or not, the server is still the same one from back in 2005!

FMS bandwidth tester

Forum Posts Resurrected

Mon, 05 Dec 2011 07:52:00 +0100

Due to several enquiries I've had over the last few weeks I have decided to put the old FlashComGuru forum back online for reference pirposes. It can be found at forum.therealtimeweb.com (or http://www.therealtimeweb.com/forum) and has been put there for reference purposes only. I have no plans to enable new signups again but would encourage people to sign up to this site's mailing list instead.

Flash Media Server 4.5 Is Out, Adds Support For HLS Video (iOS)

Tue, 20 Sep 2011 11:16:00 +0100

I know I am late to the game with this post (sorry, been busy...) but it's nevertheless worth noting that Flash Media Server 4.5 is now out.
So what's new in this version? Most notable is the support for HLS streaming - with this FMS is now capable of delivering live and on-demand video to devices and HTML5 browsers supporting the HTTP Live Streaming (HLS) and HTTP Dynamic Streaming (HDS) formats, which most importantly includes iOS devices.
Now despite what some sensationalist 'tech blogs' would have you believe this is not 'Flash-free Flash on iOS'. Instead this new feature offers the possibility to deliver a particular piece of video content to more than one platform via FMS. The server achieves this by repackaging the existing video file into a compatible format for delivery over HDS and HLS. This means that publishers don't have t worry ahead of time about the platforms they want to target and can now deliver the same piece of media to both Flash and iOS.

Check out FMS 4.5 and download the free developer edition from Adobe's website.

Configuring RTMFP Unicast on EC2

Wed, 20 Jul 2011 12:21:00 +0100

A few weeks ago I was testing some of the FMS4 features on a Windows EC2 instance. My goal was to use RTMFP (usually used for peer to peer communications in Flash) in a client-server mode, basically replacing RTMP in order to achieve lower latency.
In case you do not want to read the entire post below, here's were I went wrong:
1) I did not open port 1935 over UDP, only TCP. As it turned out, RTMFP does require port 1935 over UDP for the initial contact. 2) I didn't configure the HostPort directive in Adaptor.xml correctly. Instead of adding the public attribute I had added the IP just to the node valu.
Instead of
:19350-65535
I had configured
50.19.224.164:19350-65535
After correcting that I was able to connect via RTMFP. This also works when the Windows firewall is turned on, all I configured there was to allow the FMS .exe files through.
So that's the solution - more detailed info follows below.

At first I could not get client-server RTMFP to work. Using the standard setup and install process, RTMP connections to my instance worked fine but RTMFP connections seemed to hang for a few minutes before eventually failing.
Initially I had tried to configure the elastic IP of my instance (hint: if you are new to EC2: the elastic IP is essentially the instance's static IP that is assigned at that time but which can be changed) using the hostport in fms.ini. Removing the IP from fms.ini's hostport directive re-enabled RTMP connections via the public elastic IP. RTMFP connections failed. The logs gave me these errors:

#Fields: date time x-pid x-status x-ctx x-comment
2011-06-10 09:07:41 3456 (i)2581173 FMS detected IPv6 protocol stack! -
2011-06-10 09:07:41 3456 (i)2581173 FMS config -
2011-06-10 09:07:41 3456 (i)2581173 FMS running in IPv4 protocol stack mode! -
2011-06-10 09:07:41 3456 (i)2581173 Host: ip-0A50DD0A IPv4: 10.80.221.10 -
2011-06-10 09:07:41 3456 (e)2631013 Failed to create listener for adaptor _defaultRoot_, IP 50.19.224.164, port 80: TCCommBridge::createListener 50.19.224.164:80/v4: bind failed!!!. -
2011-06-10 09:07:41 3456 (e)2631013 Failed to create listener for adaptor _defaultRoot_, IP 50.19.224.164, port 443: TCCommBridge::createListener 50.19.224.164:443/v4: bind failed!!!. -
2011-06-10 09:07:41 3456 (e)2631013 Failed to create listener for adaptor _defaultRoot_, IP 50.19.224.164, port 1935: TCCommBridge::createListener 50.19.224.164:1935/v4: bind failed!!!. -
2011-06-10 09:07:41 3456 (i)2631174 Listener started ( _defaultRoot__edge1 ) : localhost:19350/v4 -
2011-06-10 09:07:42 3456 (e)2631114 Failed to start listeners for adaptor _defaultRoot__edge1. -
2011-06-10 09:07:42 3456 (e)2791225 Failed to start edge : _defaultRoot__edge1

Luckily Seth Hodgson from Adobe stepped in and provided tons of great info,. Here's what he told me.

In the Adaptor.xml config file for your FMS server, you'll find an section. Make sure that this is enabled, and then take a look at the following sub-element: /Adaptor/RTMFP/Core/HostPortList/HostPort

When you're running an RTMFP adaptor behind a NAT you need to specify the in-front-of-NAT IP address that your clients will be connecting to in the optional 'public' attribute for this element. Like so:

:19350-65535

Additional background: The port range here, by default 19350-65535, is defined because each FMSCore process that starts up (and the number of these depends on the number of app instances you have running and how they're configured to distribute across FMSCore processes) has its own dedicated RTMFP listener/adaptor. Assume you have 3 app instances and each is configured to run in its own process; then you'll have three FMSCore processes running and each will have its own RTMFP listener running. These listeners acquire the next available port from this range as they come online. So in this case, they should bind 19350, 19351 and 19352 (assuming those ports are available).

When a new client connects to the FMS, it initially is communicating with the FMSEdge process on UDP port 1935, and depending on the app instance the client is trying to connect to, it will be redirected (this is a low-level RTMFP capability, not a traditional RTMP redirect) to the port bound by the RTMFP listener for the FMSCore process hosting the target app instance. As part of this redirect, the RTMFP listener that the client is being redirected to is also notified that a client is being redirected to it, and it sends a packet out toward the client which should be sufficient to punch a hole in the firewall allowing the redirected clients traffic back in over the new port (say, 19351).

When you're NATed, if you don't specify the 'public' attribute above then the server has no way of knowing or discovering its in-front-of-NAT-address and the RTMFP redirect will point at the right port (e.g. 19351) but will use the behind-NAT address, which the client can't reach.

Also, while allowing UDP inbound on ports 19350-65535 (or whatever smaller range you define in your FMS configs) in your EC2 firewall rules doesn't hurt, I don't think you necessarily need to do this. You're probably OK with just allowing UDP in on 1935 and UDP out on any port (allowing traffic outbound on any port may be the default behavior for EC2, but I'm not personally familiar with that).

So there you go - does your head hurt yet? :-)

Google's WebRTC Will Bring Real-Time Communications To The Browser

Wed, 01 Jun 2011 11:48:00 +0100

*** Update, follow-up post added ***

Interesting news:
http://sites.google.com/site/webrtc/home

The WebRTc project by Google aims to enable web browsers with RTC capabilities over JavaScript APIs. For me this may just be the incentive to pick up JavaScript again. For FMS this means even more pressure outside its core function of streaming video.

Some key points and features about WebRTC:
- NAT and firewall traversal
- choice of protocols such as SIP, XMPP and others
- VP8 video
- iSAC, G.711, G.722 and iLBC audio codecs
- acoustic echo cancellation (AEC), automatic gain control (AGC), noise reduction, noise suppression and hardware access
- license allows use of other codecs
- Google Talk will move to WebRTC
- royalty free use of all included codecs

From the WebRTC blog:
"Today, we are making available WebRTC, an open technology for voice and video on the web. With WebRTC, we'd like to make the browser the home for innovation in real time communications.
With WebRTC, we are open sourcing the voice and video engine technologies from our acquisition of GIPS, giving developers access to state of the art signal processing technology, under a royalty free BSD style license. This will allow developers to create voice and video chat applications via simple HTML and JavaScript APIs."

Exiting times, and you can get involved in this very new project.
If this doesn't kick FMS into gear for stepping up its efforts for RTC based apps then nothing will. I'm not holding my breath.

Why Flash Will Be Just Fine

Wed, 11 May 2011 17:52:00 +0100

I've just realised that an email reply I wrote on the FlashMedia List would actually make a good blog post. I wrote it in response to someone pointing once again to the death of Flash, brought up by mobile and HTML5.

Actually I see emerging platforms as a big opportunity for Flash, not a threat. Why was Flash successful in the first place? Cross platform consistency.

Same headaches, new platforms. Not every company has the budget to develop an app for the web, plus iOS, plus Android, plus other less significant OSs. We should not underestimate the cost savings Flash brings to the mass market (remember when everyone and their dog wanted a website?), and the only other technology that may be able to offer the same benefits is indeed HTML5 (and by that I include JS, CSS etc). So learn some of that if you wish, but I personally never much enjoyed building HTML based sites, nor do I now. Call me old fashioned, but I still enjoy building Flash applications - and get paid for doing so.

We all have been building apps for years, and now we get a whole new platform to play on. How does that align with 'Flash is dead'? It doesn't.

Remember the real reasons behind Apple's Flash ban: it wasn't because of a lack of features, or bugs, or security, it was because of the threat it poses to their App Store revenues. You know, I know it, Steve Jobs know it.

How many fellow Flash Developers are struggling to find work? Speaking for myself, I've rarely been busier. I look around me and see my clients desperate to find good AS3 coders - and failing. Not because they have all left and are coding JS now, no, but because they all have good jobs already.

So here we are again: we have Flash, and we have HTML with the only difference that all have moved on a bit. History seems to be repeating itself. And I can see Flash still keeping an upper hand and wide popularity as it matures in the mobile space because it not only runs in most mobile browsers but can now also spit out native apps. And guess what: users do not know or care how those apps were built as long as they work. And they pay for these apps, and keeping production costs down can mean the difference between an app making a profit or a loss - not everyone is a Rovio, the money will be in the long tail, mobile is no different.

I've launched one shitty Flash game on iOS and guess what, Apple sends me a few bucks on a regular basis. Imagine if I built a decent app? Do you think I could sell some copies? You bet I could.

But you don't hear about those guys that 'just' make a decent living from it without becoming an App Store millionaire, yet all those guys combined make up the market.

My prediction: HTML5 will be a hit in the long run. And Flash will broaden its appeal and stay successful.

In these exciting times it is even more of a bummer that Adobe feels to need to sue the competition, and one that actually brings value to the Flash platform. RTMP enabled mobile apps anyone?

Adobe Files Lawsuit Against Wowza. Wowza Responds.

Tue, 10 May 2011 19:12:00 +0100

Oh what a mess. I had hoped this would not happen but here we are: Apparently Adobe filed a lawsuit against Wowza Media Systems last week alleging "patent infringement and unfair competition complaints regarding Wowza's business practices".

I do not have any specific details on the lawsuit and am merely reporting to the press release I received via email from Wowza. In it Wowza's David Stubenvoll states:
"Adobe's lawsuit against our company is completely without merit, and we look forward to resolving this matter in court. Wowza's position is that it does not infringe on Adobe patents and that we have engaged only in skillful and fair competition with Adobe. For the implementation in question, we disclosed our activities to Adobe more than five years ago and continued to be open and up front with Adobe regarding our activities. It is only after five years of Wowza growth, independent technology innovation, and market leadership that Adobe unexpectedly filed this unfounded and spurious lawsuit.

Wowza has always had a policy of timely, accurate communications with all current and prospective licensees, and so we have made the decision to communicate this matter swiftly. This action is not anticipated to interrupt our current product offering or future product plans. We will continue to innovate and provide the market with the best technology at reasonable prices while we respond in court to these unfounded allegations. We remain confident in our intellectual property position and welcome the opportunity to settle this matter definitively."

Let's see how this pans out, but in the end there will be no winners. In most people's eyes Wowza have developed a top notch product and provided great support to developers, offering a lower priced and feature rich alternative to Flash Media Server.
Honestly I feared something like this may be on the horizon, but I would have out bets on an acquisition of Wowza by Adobe instead - guess that option is out of the window now. Lisa seems to agree with me.

Anyone know where I can find the details of the lawsuit?

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?

Uvault Launches New Multi-Platform Streaming Service

Tue, 29 Mar 2011 12:27:00 +0100

Long standing Flash Media Server hosting and streaming media provider Uvault have launched a new multi-platform streaming service. The new service supports both Flash as well as HLS and RTSP, and is suited to deliver live and on demand content not only to desktop computers but also mobile devices.

In addition to the streaming delivery of the content the service also offers a media management console, adaptive streaming features, a custom player wizard and extensive reporting.

Prices start at $100/month for on demand and $50/month for live broadcasts. A free trial is available.

To find out more head over to Uvault's website.

Looking For An Old Version Of Flash Communication Server?

Mon, 21 Mar 2011 22:28:00 +0100

A question that seems to pop up from time to time is where old, archived versions of Macromedia Flash Communication Server or Adobe Flash Media Server can be downloaded from. Sometimes people need to test legacy applications or simply own an old license but cannot find the installer anymore.

You are in luck. A little known fact is that all the software updaters for both FCS and FMS are in fact fully fledged installers - the title 'updater' is a bit misleading. Yes, they do update a previous version but they do so by effectively uninstalling the old version and reinstalling the new one.

Therefore if you need to obtain one of those legacy installers you can do so from Adobe's FMS Updaters page.
Scroll down - and back in time- to access all versions back to FCS 1.0. Ahhh... those were the days, eh?