Category Archives: Flash

Broadcasting: On Adobe's CS4 preview webcasts

I managed to catch half of an Adobe webcast yesterday, previewing Creative Suite 4. It seems their main focus with the release is to improve workflow, easing the integration through the software family, across the whole suite, and with that improve the production process faced by designers and developers alike.

From the outset, their recent press release promises:

“Hundreds of feature innovations.. Delivering radical workflow breakthroughs that bring down the walls between designers and developers.”

So what were they?

Well from what I saw, there’s more ‘live updates’, some things I’d seen intended for CS3 that never quite made it. There was a good demo of Dynamic Link, their platform to facilitate these, which moved video clips from Premiere to After Effects and back, in this case, without the need to render a thing – a process that would ‘usually take fifteen minutes’ takes fifteen seconds in comparison.

Illustrator can now handle multiple art boards at once, embedding them into a single workspace. Meaning others’ updates are synchronised to your working environment. These could then be imported, for example, into Flash – still in their accumulated state.

A lot of Flash and Flex events I’ve attended recently seem to have presented the same message, their attempts to converge the designer and developer, or at least bring them closer together. The new skinning and design options in Flex 4 (Gumbo) for example, or even Thermo as a complete authoring tool, seem intent on doing this.

But I’m undecided, half of me won’t trust the code any ‘WYSIWYG’ editor writes for me. I wonder if designers might soon experience a similar dilemma – Photoshop CS4 has a ‘content-aware scaling’ tool that determines for you what ‘objects’ in a flat image should be resized, or otherwise maintain ratio. See it in action here.

The other half thinks that Adobe aren’t trying to dictate my working environment to me, or forcing me to change a thing. Instead, more trying to accommodate others that might struggle and/or are new to the software, or in my interest, interactive development.

Colin Moock recently presented the ‘Charges Against ActionScript 3.0‘ at InsideRIA, continuing a discussion into whether Actionscript 3′s ‘hard’ reputation is deserved. He criticised CS3 for making ‘simple interactivity hard’ – his example proves his point, the on() and onClipEvent() handlers are no more. But it’s not so bad, just that even the most simple animations require a little more structure now.

But in comes the demonstration of the new animation features of Flash CS4, including tweening by dynamic bezier-like paths with easy and intelligent ways to modify them, ‘scalable’ timelines which automatically reposition keyframes and even creating ‘skeletons’ for MovieClips to quickly animate what would previously have required tedious dissection and some fiddly manipulation.

There’s even 3D effects in the authoring tool – effects being the keyword. I can’t help but think this is the direct result of the impact and rise in popularity in some powerful open source 3D engines, like Papervision and Sandy. The demonstration didn’t impress at all compared to some of the samples from the aforementioned. I wouldn’t be surprised if in a similar vein, some ‘light’ physics simulation could soon be introduced.

The repeated message from Adobe; what previously took the time of a developer to write parameter-based code, whether for interaction or animation, can now be done by a designer in half the time, what they almost suggest, for half the price – because it’s now twice as easy.

I’m sure there’s some more showings today for southern hemisphere timezones, but a whole load of video tutorials are playing over at Adobe TV that are well worth checking out. Everything else can be found at the CS4 homepage.

Trial and Error: Getting started with 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 http://code.google.com/p/red5/ – I hope this results in a better exposure for Red5 and an increase in popularity – and as a choice for developers, too.

Before I Forget: Flex Camp 08

I should have mentioned already what an awesome success Flex Camp 08 was a couple weeks back. London’s first go hosting the show, huge well done to the London Flex Platform User Group, the guys at Emak Mafu and everyone else involved in arranging the event. The day was made up of various show and tell sessions, panel discussions and workshops, all for free, needless to say those who couldn’t make it sorely missed out, irrelevant of the free beer and pizza by a long way.

Andrew Shorten, Adobe Platform Evangelist, opened with a keynote similar to Mark Anders‘ recently at 360 Flex (found via InsideRIA), reviewing Flash development since 1993 and looking at the roadmap ahead, toward Flex 4, Gumbo – and tools like Thermo and Degrafa. We got some sneak peeks at Flash Player 10, previously ‘Astro’, not only showing off some cool effects like Pixel Bender, but interestingly with those, further steps made by Adobe toward the more open source development community.

A couple highlights, I enjoyed Justin Clarke and Samuel Williams rattling through their presentation on PureMVC. I’ve used PureMVC before, but as frameworks go, I generally always adopt Cairngorm for the majority of Flash and Flex work, but they’ve definitely convinced me to have another look.

As good was Bryan Hunt of Emak Mafu delivering his brilliantly disgruntled thoughts on working with Flex and Java, something I’m yet to try, but he also touched upon developing with the Spring framework, which I’d recently come across working with Red5 – glad I caught up with him afterwards.

Perhaps the most useful was Peter Elst‘s class on using SQLite and AIR, in which he quickly put together an app with a simple straightforward relational database, using very little MXML and Actionscript, demonstrating the SQL database support in AIR as standard with AS3, as well as it’s capabilities in synchronising with online sources.

I’ve seen a couple requests around for any source code or presentation slides from the day, but I’ve yet to find any – if I do I’ll update here, I’m keen to see them myself.

Steady Rollin’: Flash Media Server, Red5, CDNs and gaming (Part 2)

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.

The Gambler: Flash Media Server, Red5, CDNs and gaming (Part 1)

At the beginning of April I was invited to the most brief and preliminary of development meetings concerning a forthcoming project, then only a concept for a web-based, live mass-participation game show. We were told it would be exclusively online, combining a high-quality live video feed of a presenter-led programme, facilitating up to 1,000 paying contestants to simultaneously compete for real money prizes with a number of interactive games.

I was invited because the primary candidate for deployment was using Flash Media Server, which I had a intensive experience with in my final year of university. Primarily I was asked whether the project was feasible, achievable and did I feel using the FMS the right approach technologically, because no one else on our team had previous dealt with it. Although less than a year since my work at uni, it was quite apparent that the scale of the project was going to be significantly more demanding than anything I’d worked on before, but I figured I say yes anyway.

The project itself is deceptively complex, but stubbornly never so in explanation. Essentially, it’s a enriched online port of the infamous interactive game shows despised on late-night television – you know the ones with premium rate numbers and supposedly con viewers? They’ve all pretty much been scrapped now, so this idea was (and because it had to be) a completely new format – the idea of a game of skill, with straightforward general knowledge and trivia as opposed to frustratingly ambiguous questions; without the premium rate number to join a queue of callers, instead, an approx. 25p entry fee that goes to an accumulative pot entitling you to answer all questions posed. The eccentric presenter remains, the live video stream remains as-near-as-we-can-to-broadcast quality – the exception being the intended hundreds of players compete simultaneously, meaning every question and answer must be timed, recorded, logged and audited with a robust and secure system.

I only truly realised the scope of the thing after so eagerly agreeing to build it when I began to comprehend the vast difference between this project and that I’d previously built at uni. We had a substantial amount of R&D time to really consider whether FMS was our best option, it’s capabilities, limits, the licensing – and being the only member of the team with any experience with the FMS, we were cautious to commit if it could be achieved some other way we might feel more familiar with – an open socket model with Java or PHP maybe – but FMS eventually won through.

The project required was a standalone engine to run, load and dispatch data, make remote procedure calls to server-side scripts, all independent of any administrator control unless commandeered. At this point, looking back at Talkboards which stored all dynamic data in persistent shared objects the user simply subscribed to, its entirety was equal to the live chat ‘feature’ alone.

Building this engine immediately began to highlight Adobe’s lack of development with the Media Server since obtaining it. It’s still pretty much Actionscript 1.0 – or near enough, their API confesses ‘Server-side Actionscript’ is just their name for JavaScript 1.5. So OK, back-date the code – and no type declarations unless you want the app to silently unload, but there’s also no use of the Delegate or EventBroadcaster – arguably the backbone for Actionscript development. I also wanted to avoid using prototype functions where I could and try to divide the code into some kind pseudo-class system – not only to be more logical and readable, but for any later hand-over or joining of other developers to the process. But this could only really go so far to contextually separate ASC files that all load from the app’s main.asc anyway.

Problems with the absence of the Delegate and EventBroadcaster are obviously not uncommon. Peldi ported the classes to ASC files in his handy Flash comm server book, some hosting services, such as Influxis, bundle their own frameworks with hosting packages. But the more complex the objects and lengthy the extensions from the top-level Client and Application classes, the more scoping errors I encountered.

Jesse Warden wrote an interesting article concerning the Observer pattern experiencing the same problem developing Flex applications:

“With a little work… you can implement FMS server-side components into Cairngorm 2. For ever server-side component you create, you merely create a client side equivalent as an Observer. It listens for NetConnection or Remote SharedObject sync events and dispatches events. These events run Commands which in turn set data… just like normal. If your Views are bound to said data, boom, you’ve got a nice, clean separation.”

Ultimately we devised a model that essentially handles quite a complex (application) data object, passing itself around via prototype functions, making amendments and modifications and passing itself on. Each client has their own (client) instance (that extends the Client class), enabling their unique connection to call server-side methods – and vise-versa – without needing to loop around the application.clients array.

And finally, last Saturday was the pilot launch. Initially a beta test group of 100 competition winners and by and large, it went extremely well. Surprisingly, the biggest infringement was on behalf of our PHP/MySQL host, who happened to have hardware difficulties that day. So although all still proceeds to go well, I won’t count my money at the table, episode number two is tonight – with an increase to 300 users.

I ain’t here for business, I’m only here for fun.