Category Archives: Red5

I briefly mentioned before that I’d started looking at Red5, the open source RTMP server, as a viable solution for a scaling a recent project I’d been developing. Essentially Red5 is the open source equivalent of Adobe’s Flash Media Server, on which the project is currently built, but the proposed migration seems to offer more benefits than just the removal of the expensive licensing overhead.

Currently we’re working with a shared hosting solution, allowing up to 500 concurrent RTMP connections, but our intent is to scale up to over double that figure – aiming to ultimately handle between 2,000 and 5,000 clients. Regardless of the licensing cost that would ensue and the requirement then of (probably multiple) dedicated servers instead, we see Red5 to present a good opportunity to upgrade the system as a whole, to strengthen it and make it far more robust, rather than just straightforwardly translating the application across to the new platform. We’ve recognised for example, that there would be more room for control, observation (and logging even) with a ground-up custom application than we’ve experienced so far with Flash Media Server – worsened of course, by the shared hosting.

So I went about looking into migrating our FMS app, reading a lot of ‘Getting Started with Red5′ type material, of which I definitely recommend Joachim Bauch‘s FCS/FMS to Red5 Migration Guide and his ‘how to’ on Creating New Applications, for anyone else looking. I began collecting helpful bookmarks (see here) and there’s plenty on the OSFlash site too, but I soon realised whilst the fundamental structure and the core concepts of the system could remain, a ‘straightforward’ migration wouldn’t be possible anyway.

Red5 is written in Java on the Spring framework, obviously running compiled Java code as opposed to Flash Media Server interpreting, basically, JavaScript. I wrote the system on a structure of pseudo-classes, dividing code by concept where the nearest thing to classes the server could support were extended object ‘prototypes’. Further than that, separating the code files, but essentially the main.asc initialising script loaded everything in-line at runtime anyway.

Here’s the opportunity then, by developing in object oriented Java, to consider every part of system as a separate construct or component. Previously when trying to extrapolate code, I’d be pulling out methods from prototype functions where scoping problems seemingly wouldn’t allow it any other way, everything was very bespoke. Developing this way would not only promote a better coding standard, but perhaps produce reuseable components, for example, the part of the app serving a rudimentary chat system. But this stuff is like version 50, end of the roadmap, before I’d written a Hello World yet, only then I could consider more RTMP, remoting, then onto sync’ing shared objects, etc.

There’s plenty of resources around to get started with, John Grden at RockOnFlash has some good samples. Milan Toth wrote a handy article from setting up your server environment through application development, to the final Flash client that proved useful, but there were a few frustrating not-so-well documented issues I repeatedly came across.

I think a lot of the issues were with the most recent version of Red5 I was using, v0.7.0, final release as of February this year, but with the majority of tutorials predating that release with now deprecated code. Most commonly I found I was being given a 404 errors when I’d uploaded bad code, relatively straightforward, except it took an annoying amount of time to realise this when I would’ve expected perhaps a 500 error in such a case. Furthermore, I couldn’t find any ‘errors’ in my code, even those I directly copied and pasted from tutorials or recompiled from free source threw the same problems – surely then it would be a problem with my development environment.

Some tutorials compiled .jar files, some with ANT or within Eclipse, some solely used compiled class files. I found my problem to be central to logging, specifically with the log4j library, which when I removed all references to, managed at least to get a directory listing from Jetty and the application instance to appear in the admin console. Other problems I encountered later attributed to using a too-recent JRE, schoolboy.

I always find Hello World and the first initiation with any new platform or language to be a big step, this taking some time with Red5 for me, seems to have landed me in a better place to move onto shared objects, remoting, live publishing, whatever, up next.

I’ve also noticed the developer mailing list has gotten much more activity lately and with it, become far more useful. I definitely recommend subscribing to that for anyone looking to develop with Red5.

Also, the SVN repository has recently moved over to Google Code, found now at – I hope this results in a better exposure for Red5 and an increase in popularity – and as a choice for developers, too.

Note: this post is a continuation of my previous article, The Gambler.

In my last post I spoke about my development on a recently launched live mass-participation game show. Since then the show has had three, very reasonably, successful broadcasts running 9pm til midnight Thursday across to Saturday. Grateful to the forgiving pool of beta testers who excused the previous technical dilemmas when we had them, the recent shows seem to have gone almost completely without hitch.

Being a hybrid format aiming to balance as much the creation of a social gaming community as extending the achievements of the original television channel, it’s interesting to explore how just as many of the inevitable teething problems we’ve encountered, have in fact, been outside of the technical scope. These problems instead, have been found to be more part of the process of migration to the new adaptation. The beta test group has grown to over five hundred users, with that, some unexpected and quite interesting trends have begun to emerge.

Initially, understandably taking off from the success of the original programme, the focus of the project was seen to be the live video content – the presenter-led broadcast with eccentric compere, who would introduce and commentate on the games in progress. This was key, and second came his interaction with the players, a communication only made possible by the translation to an online platform. This idea held quite innocently, saw the show as a direct port – the show simply delivered online – with just a change of viewing medium. What wasn’t predicted however, were the behavioural changes of online contestants, given now, that their level of participation has been radically reversed with it’s re-imagining, perhaps so much so, that this priority focus may need to be altered.

Previously the only way of answering questions for example, was by a single, individual phone-in effort at the (literal) cost of the player. This could only occur one at a time of course – and presumably then, one could not accurately know until the declaration of their answer, how long a single game could last. Now however, all players have free access and the opportunity to answer all questions, so there is no single ‘spotlight’. Short of a low threshold profanity filter, there are no barriers holding back players voices. As a result, the integrated chat client is furiously active, but an intriguing place. The users are already beginning to build the intended community sphere, but as much a place of social interaction, guaranteed after the final question of each game will the players begin comparing answers, scores, offering the most sincere congratulations and commiserations.

They are offering each other as much, if not more entertainment, than the assumed center of attention – the presenter. In some cases, the production team, not grudgingly, succumbs to the demands for more and more immediate and frequent games. The players too are beginning to see a shift in who really has control of the show. This confirms even greater still, the need for our technical system to be hardily stable and reliable. As online users become more demanding, the less compromise they (quite rightly) feel the need to offer in search of their own entertainment.

With most of the bugs and glitches ironed out of the game engine which now steadily ticks over as it should, the only remaining problem of any substance is the delivery of that live video broadcast. Acknowledged early on, the audio and visual quality would not be equal the digital television picture they’d previously broadcast, but we endeavoured to explore any way to best achieve something as near to that as possible. We also had to consider the amount of data being transferred to achieve this. Surely out maths must be wrong – with video at 300kbps, audio at a variable 128kbps, for three hours, for three nights, for up to one thousand users.. we abandoned the calculations when they began needing measurement in terabytes per night.

Instead we use a bespoke content distribution network (CDN), who specialise in mass content delivery, specifically designed to distribute large amounts of rich media. We push to one URI, essentially another Flash Media Server (the Flash Streaming Server equivalent of the Interactive Media Server) and it’s bounced around various worldwide locations, which each client subscribes to. We’ve had intermittent success with Limelight Networks, but this week will be changing over to Akamai, who boast leadership in streaming media services, hopefully to solve our remaining issues.

The beta phase will continue for a further three weeks, over which time the audience figures will steadily rise. Future projections intend the system to reliably run for up to one thousand users, a figure we currently see confidently attainable. Beyond that stage, only now beginning to be considered, will need to bring more significant architectural changes. We’ve discussed using multiple Flash Media Servers for the game engine, whether sharing the load or sharing the connections – or construct some hierarchy of master to slave servers.

Although with Adobe’s release of Flash Media Server 3 the licencing costs have been dramatically reduced, the overheads will amount regardless. With that in mind, I will start to look at running Red5, an open source Flash RTMP Server – essentially the open source equivalent of Adobe’s FMS, as it becomes more stable and nears it’s first public release.

Be sure to check out it’s roadmap. And other open source Flash projects.

You ain’t a beauty, but hey you’re alright.