FCS and RTMP – Streaming Technologies from the future

I remember clearly the enthusiasm and excitement when I moved my first steps in streaming and real-time communication. I was already fond of video compression and interactive web and was working actively with Flash community to create interactive experiences, but my career took a turn when Macromedia released Flash Communication Server 1.0. It was September 2002 and after 20 years the RTMP protocol, one of its foundational technology, is still among us!.

Pritham Shetty (helped by Jonathan Gay – the father of Flash) was the ingenious main author of this milestone in the history of video streaming. Pritham had already an extensive expertise in real-time communication for the web and for example, in 1996 he developed for NTT a Java based web client for connecting multiple users in a synchronized experience. And again, in 1996 a personalization server he developed was used even by Netflix! (when it was still very distant from the company we use to know today).

FCS was an exceptional server capable to enable real-time communication, live and on-demand video streaming features in Flash Player 6.0. The architecture of FCS was really ahead of its time and when I started working with it I had only a 640Kbps down/128Kbps up ADSL connection and a 64Kbps GPRS phone and nonetheless it was possibile to communicate in real time with other users over such connections and create futuristic interactive applications.

As we all know, 18 years after this exceptional release, the entire world has depended on real-time communication technologies like Microsoft Teams, Google Meet or Zoom because of Covid-19 pandemic. Think of FMS as a playground where Flash developers could easily develop video conference applications similar to those, with multiple audio-video-data streams produced in the browser by Flash, transported via RTMP protocol, orchestrated server-side by FMS and consumed again on a Flash Client.

I think the main advantage of this stack was simplicity and elegance and I’ve always used the lesson learned with FCS in my career as an Architect of Media Solutions. At the FCS’s foundation there was a non-blocking I/O stack scriptable in Action Script 1.0 (essentially JavaScript). Every user connection, application startup, disconnection and in general interaction raised an event and the code responded with actions or async I/O operations to connect RTMP streams in publish mode to RTMP stream in subscription mode and orchestrate via script many other interactions and data sharing (Curiously the architecture is very similar to Node.js. When Flash was abandoned I started easily to work with an early Node and FFmpeg to substitute many of the use cases I used to serve with FCS).

The simplicity and high efficiency of RTMP is also the main reason why it is still used today. RTMP allows to stream interleaved audio, video and data tag on TCP, SSL or tunneled in HTTP(S) and it’s possible trasparently to pass from real-time (few ms), to live and to vod use cases, with RPC call interleaved in the stream and easily recordable for interactive reproduction of communication’s sessions.

When working with this stack you had literally infinite possibilities a decade before webRTC was conceived and I ended to be an expert in FCS (then known also as Flash Media Server / Adobe Media Server) developing many advanced applications in the next 10 years (for example, thanks to the flexibility of the duo Flash + FCS I was able to design one of the first implementation of adaptive bitrate streaming for the first catch-up TV in Italy in 2008). 

Unfortunately FCS/FMS/AMS has not had the success and the widespread diffusion it deserved because of an absurd and limiting pricing model by Adobe. Nonetheless it has left an undeniable contribution to the Internet streaming.

Happy 20th Birthday RTMP and kudos to the great FCS and its authors.


Adobe Media Server 5 announced

Adobe has announced that the new Adobe Media Server 5 (formerly Flash Media Server) will be available soon. The change in the name reflects the recent shift in strategy of Adobe [sarcastic mode on] that is running away from Flash as fast as possible to embrace more cool technolgies like, in this case, HLS [sarcastic mode off].

Irony apart, I’m very happy with this announcement because I have always stated that FMS could have interesting new possibilities supporting streaming for iOS with content protection. FMS supports HLS streaming since release 4.5, but this is not sufficient to keep the leadership.

I work for large media clients that need content protection and in the last 2 years I have seen such clients choose MS’s SmoothStreaming and PlayReady too much times because some independent vendors have been able to offer them native clients for iOS supporting PlayReady DRM inside HLS protocol.
So it’s impossible to remain on the technology and adoption edge if not supporting all the business needs for the most preminent mobile platform.

Now with AMS 5 we are able to use our preferite streaming server to deliver protected content to iOS device too, both in applications created with AIR as well as native ObjC apps.

We have two protection techniques: full blown DRM protection using Adobe Access 4 (again “Flash” is flashed away) or using PHLS (Protected HLS) the HLS version of PHDS (Protected Http Dynamic Streaming).

This last feature is indeed very interesting because offers a stronger protection than the very simple encryption possible with standard HLS without requiring the costs and worries of DRM servers.

More info in the Kevin Towes’ Blog