Author Archive: Ryan OConnell

Transitions Sample

A popular question on the forums and with player developers is how to use transitional effects on media elements.  A common transitional effect is a fade to and from black.  These transitions help ease the transition from content to ad.   I’ve written a small sample to demonstrate how to do this with the framework.  It’s a reusable effect that utilizes the Flex Fade effect.  Here is an excerpt from the sample:

var video:MediaElement = new VideoElement(new URLResource(REMOTE_PROGRESSIVE));
new MediaElementEffect(10, video); = video;

Full Sample:

The class that performs the transition is the MediaElementEffect, which takes two constructor params: a duration and the media element the transition will target.  In the above case, the transition will be ten seconds.  Clicking the stage will restart the video and effect from the beginning.  
Other effect frameworks, such as Tweener, can be swapped in and out. The effect type can be changed as well, to something such as dissolve.  To override or change the effect override the doTransition() function in MediaElementEffect

We’ve been listening

At the end of the Beta period we sent out a survey to ask for feedback on the framework to date.  We also took the top issues reported on the forums.  Here are some of the highlights of this project:

MediaPlayerSprite - At the end of Sprint 10, the API lockdown sprint, we removed the MediaPlayerSprite. Not knowing the huge number of developers that wanted this functionality, we received feedback from developers that the MediaPlayerSprite was a much needed class. 

For Sprint 11 we’ve retooled the MediaPlayerSprite, added some improvements, and brought it back.  It now supports handling a resource directly, and has its own media factory.  It exposes the MediaContainer it uses internally for better layout control and flexibility. This reduces the complexity in creating players.  A player can be created in as few as three lines:

mps = new MediaPlayerSprite();
mps.resource = new URLResource(REMOTE_PROGRESSIVE);
For a complete sample on how to use the MediaPlayerSprite, it’s located under trunk/samples/framework/MediaPlayerSpriteSample in our SVN repository. 
Other feedback we’ve addressed recently:
Subclips – Use StreamingURLResource, along with clipStartTime, and the clipEndTime properties to make subclips.
MediaPlayer - property persistence, and more trait events. The MediaPlayer now preserves trait settings, such as autoPlay, and bufferLength, even if the MdiaElement is changed out.  The trait events will be dispatched for new MediaElements when they are assigned to the MediaPlayer.  This alleviates the need for developers to listen for the Trait add / remove events when tracking properties, such as volume. 
DVRCast – A little known feature, bis support for DVRCast.  DVRCast was added in Sprint 10. Here is an example of a DVR resource:
new StreamingURLResource
( “rtmp://”, StreamType.DVR)
Media & Streaming Types Supported – Another request we received was an aggregation of the different types of streaming supported, and ways to use them:
  • Progressive – URLResource to a videos url
  • RTMP Streaming – URLResource to an RTMP stream
  • RMTP Dynamic Streaming – DynamicStreamingResource to an FMS app, and a list of stream names.
  • HTTP Dynamic Streaming – URLResource to a  F4M manifest file. (uses the F4MElement)
We also have some projects planned to address some of the other requests we’ve been getting.  On the horizon in the next few weeks:
  • Layout and Cuepoint white papers.
  • Code Examples on how to use transitions between MediaElements.
In addition we’ve been busy fixing bugs now that we are feature complete.  We’ve fixed 206 bugs in the last thirty days (as of 4/2/10), here is a graph of all bugs fixed & reported in the last 30 days:

Using Dynamic Plugins

The plugin framework for OSMF can appear complicated at first glance, but from the point of view of a player developer, it’s actually fairly simple. Loading plugins can be as simple as one line of code added to an existing player. Early versions of the framework required the plugin exist on the same domain, but now the framework can load plugins cross domain, given that the player is hosted from an http:// url and the plugin is also hosted from an http:// url, and the plugin’s webserver has the appropriate cross-domain policy file in place. This means loading a player locally (using a file:// style url) won’t work with dynamic plugins. A local webserver is the suggested setup.
Using the PluginManager, a plugin can be loaded in one line of code. The following code snippet demonstrates how one might load a CDN plugin:


private var mediaPlayerWrapper:MediaPlayerWrapper = new MediaPlayerWrapper() ; 

private static const REMOTEPROGRESSIVE:String = “”;

private static const PLUGIN_REMOTE:String = “”;
private var manager:PluginManager;

private function init():void

manager = new PluginManager(new DefaultMediaFactory());
manager.addEventListener(PluginLoadEvent.PLUGINLOADFAILED, onPluginFailed);
manager.addEventListener(PluginLoadEvent.PLUGINLOADED, onPlugin);

manager.loadPlugin(new URLResource(new URL(PLUGIN


private function onPlugin(event:Event):void 

mediaPlayerWrapper.element = manager.mediaFactory.createMediaElement(new URLResource(new URL(REMOTE_PROGRESSIVE))); 


private function onPluginFailed(event:Event):void



The above code snippet will attempt to load the plugin at This line needs to be changed to the location of the plugin the player wants loaded. For instance it can be changed to the location of the Akamai plugin, once Akamai releases their CDN plugin.

This feature releases the player developer from having to maintain plugin code. It allows bug fixes and updates to reach players using 3rd party plugins, without having to recompile players.