Skip to main content

ActionScript: Flowplayer vs. Open Source Media Framework

I've been playing around with Flowplayer, which is an "Open Source (GPL 3) video player for the Web". I decided to check out the Open Source Media Framework (formerly known as Strobe), which "enables developers to easily assemble pluggable components to create high-quality, full-featured playback experiences." In short, if you need a Flash video player today, stick with Flowplayer. The OSMF just isn't ready for prime time. It's a large framework written by a large company (Adobe). It's not a simple, hackable video player that you can throw on a production website in a couple of hours.

The website reeks of corporate speak. For instance, here is part of the page that talks about plugins:
One the primary goals for OSMF is to provide a set of standard APIs for video ecosystem service integration so that player integration is no longer a barrier in the market. The framework will have a plugin API that allows for integration of client-side code for the full range of ecosystem services, including media delivery, media composition for advertising, event reporting for audience measurement, and other rich experiences. The plugin API is designed to support dynamic plugins as SWFs and integrated plugins as SWCs in a way that makes it straight forward for the same provider to support both scenarios.
When I read the document for writing a plugin, it sounded more like a functional spec than real documentation:
Summary of Features: User Story: As a plugin provider, I need examples for how to create a media plugin and ideally a basic composition plugin. I also need the ability to specify when a specific version of my plugin works with a specific version of the Strobe framework. If a player tries to load a version of my plugin that the player won't support, the framework should be aware and pass info through for graceful error handling. I also want to be able to support multiple versions of my plugin.
I clicked to read the Developer Documentation, and the only thing they had was "On-line API Documentation". That means they ran a tool like JavaDoc to pull the comments out of their source code. In fact, the tool mixes the API documentation in with the normal ActionScript API docs:
Overview of the ActionScript 3.0 Language Reference
including the Open Source Media Framework API
The one thing the OSMF has going for it is that the source code is very regular and clean. It's large and Java-esque, but at least the style and comments look regular. Flowplayer's code isn't bad, but I wouldn't call it "polished".

The OSMF requires Flash 10, whereas I was hoping to stick with Flash 9 since the adoption rate is higher. Here's a comment from another poster:
While I am sure OSMF can do well with small content media companies, I find it hard to believe that large media content companies will join before flash player 10 penetration is about 96% - 98%. The reason OSMF compile for FP10 is that OVP uses some of the new features in FP10 to do dynamic switching etc, it can be modified so OVP doesn’t uses the FP10 capabilities and will position the framework better.
Based on looking at this blog post, the OSMF doesn't even provide default player controls. That's a heck of a lot of code to not even provide player controls!

I don't know a lot about ActionScript, but I do know a lot about open source. Open source projects tend to tend to go nowhere unless they address the following:
  1. The code must be easy to build and do something useful by default.
  2. If it's a library, the documentation must make it very easy to get started. Framework API docs don't count.
  3. The code must be stable. (I haven't run the OSMF, so I can't comment on that.)
  4. It must be easy to hack the code to accomplish what you want.
  5. It must be easy to contribute back to the project. (I can't even look at the existing OSMF bugs without creating an account.)
Frameworks start out life with 2 strikes against them because they don't do anything useful by default, and they take a lot of time to understand. In contrast, applications (like Emacs or Firefox) do do something useful by default, but are still straightforward to customize.

In summary: It requires Flash 10. It doesn't have player controls by default. It's written like a massive Java framework. It lacks good documentation to help you get started. It does have nice source code, but at this point, it's simply not a viable alternative to Flowplayer.


jjinux said…
Brad I./24/M/RockIsland,IL recommended
jjinux said…
Yeah, LongTail looks awesome! I love the number of sheer volume of useful plugins they have.
jjinux said…
Kamil B./30/M/ZielonaGóra,Poland wrote:
"You can try players at, they have range of choices there."
flexy said…
Hey, interesting read, but I have a few comments:

Flash Player 10 is currently at 93% in mature markets, and at least at 90% in all other markets. These stats were recorded in September, and I would imagine that FP10 will reach the figures you stated you require within the next quarter.

OSMF is still very young and not yet at its 1.0 release. You could be right that it may not yet address all of the features of FlowPlayer 3.5, but that's not to say it (and players people build using OSMF) won't in the near future.

Adobe deliberately aren't pitching OSMF to the beginner/intermediate ActionScript community at the moment for exactly the reasons your cite. OSMF is geared at the developers who build players like FlowPlayer, not necessarily the people who consume FlowPlayer.

For the record, I don't work for Adobe, I'm a developer who has been following the OSMF project closely for sometime.
jjinux said…
Flexy, thanks for listening to my ravings, and responding with useful comments ;)
Unknown said…
Hey, Thanks for the review. I have a couple of comments. The OSMF is built on top of the open video player source code

So controls are built in,maybe just a little more difficult to implement than say flowPlayer. I have been comparing the two players for a streaming video player with akamai's service. For us OSMF is the winner. Out of the box it supports akamai streaming as well as plug ins for ad support. For what is not built already it is easily extensible to a developer who knows as3.

jjinux said…
Thanks for the comment, gevan. I've been pretty happy with JW Player for the last week, although I haven't finished tweaking it yet.
flexy said…
It's probably worth adding at this point that Open Source Media Framework (OSMF) and Open Video Player (OVP) are two separate projects and shouldn't be confused.
jjinux said…
Thanks. I haven't looked at the OVP at all.

It turns out that JW Player version 4.6 best addresses my needs. It supports bitrate switching, but only requires Flash 9. It's also been pleasant to hack on, aside from requiring CS 4 (version 5 doesn't).

I'm sure the situation may be different 6 months from now as JW Player 5 implements bitrate switching, Flash 10 becomes more common, and the OSMF is further along.
flexy said…
My feeling is that if JW Player is supporting bit-rate switching with Flash Player 9 it isn't the true 'Dynamic bit-rate switching' offered by Flash Player 10 and FMS3.5. It is possible to switch between streams without the new player or server, but I expect it won't be completely seamless. If that isn't the case, I'd be keen to find out :)
jjinux said…
I was watching a video at full screen, and it was switching dynamically. It only works with FMS. I don't believe Flowplayer could do it seamlessly, but it's something that drew me to JW Player.

"However, if the RTMP server is Flash Media Server 3.5, the level is continously being evaluated (every 2 seconds), in a mechanism Adobe calls dynamic streaming." See:
Chetan Sachdev said…
I agree, OSMF isn't as flexible as flowplayer. As OSMF is still in its beta phase. But before choosing a player, I take a look at how much customizable it is. FlowPlayer in that sense, is easy, with integration of plugins. So, +1 for flowplayer :)
S Raaj Nishanth said…
Now that OSMF is out of the beta phase and is quite evolved, what would your current review be? Will the above review still hold good?
jjinux said…
Sorry, I haven't tried OSMF since it's out of the beta phase, so my review would need to be re-evaluated. Unfortunately, I don't have time for that right now.

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p