We’ve posted the ZIP file for the latest stable OSMF release. New features include:
- Live Stream Support. Player developers can now specify the stream type (live vs. recorded vs. either) when connecting to FMS.
- Subclip Support. This feature allows for playback of subclips, or contiguous sub-sections, of a streamed video, which lays the groundwork for presenting mid-roll ads.
- Captioning Plugin. We’ve implemented a new plugin that can handle captioning for OSMF-based players, using the W3C’s DFXP timed text format.
- Flash Media Manifest Support. Adobe is proposing a new XML format for representing a Flash Media asset (including MBR information) and its related metadata. The latest drop supports this through the F4MLoader class.
- Preassigned Durations. You can now specify a default duration (via the defaultDuration) property on VideoElement and AudioElement, so that the media can reflect its duration before playback.
- CompositeElement support for bytesLoaded and bytesTotal. In a previous sprint,we added support for tracking download progress for a single VideoElement. Now, you can track the download progress when your video (or other downloadable media) is part of a composition.
- Improved Metadata Merging Support. CompositeElements now reflect the metadata of their children. The Metadata API exposes finer-grained control over how a child’s metadata will surface on its parent.
In addition, we’ve made great progress in refactoring and renaming our core APIs to address customer feedback, and to be more consistent with other APIs in the Flash Platform. In the short term, this means that virtually every player and plugin built on top of previous versions of OSMF will need some code changes to integrate with the new APIs. (The release notes contain a summary of these changes, as well as some tables with the old and new names, which should be helpful when updating your app.) In the long term, this moves us one step closer to solidifying our APIs and our 1.0 release.
And now the links:
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 = “http://mediapm.edgesuite.net/strobe/content/test/AFaerysTalesylviaApostol640500_short.flv”;
private static const PLUGIN_REMOTE:String = “http://example.com/samplePlugin.swf”;
private var manager:PluginManager;
private function init():void
manager = new PluginManager(new DefaultMediaFactory());
manager.loadPlugin(new URLResource(new URL(PLUGINREMOTE)));
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 http://example.com/samplePlugin.swf. 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.