Selecting a media player for your project

There are a number of options to consider when selecting a media player for a project. Recently, I had a large media panel to build and which player to use was likely the most important piece of the puzzle.

Here are the factors I used in determining which media player to use:

  • Speed – How fast did it load?
  • Interface – How easy was it to use?
  • API – How easy will it be for me to work with?
  • Documentation – How easy will it be for me to figure out how to work with it?

There are three players I considered primarily. There are many others I looked at, but these three were a clear cut above the rest.

Here’s the break-down of them, and we’ll start with the least compatible for the tasks I was trying to accomplish.


In a world moving rapidly towards trying to accomplish 100% cross-platform content compatibility, especially with the recent proliferation of HTML5, new tools are a constant need. MediaElement.js is a giant step forward in this area. It takes the hodgepodge of various presentations throughout the browsers, and consolidates them into one consistent presentation.

The good:

  • Very slick presentation. Allowing the control panel to be completely within the HTML/CSS means you can make any sort of change you need. As I’m planning to add at least one button later, that was a definite bonus.
  • Consistent presentation across platforms.
  • Allows us to use the HTML5 <video> and <audio> tags, to let the latest browsers handle the video natively and then allow us to fall back to other players for less capable browsers.
  • It supports both a fallback Flash and Silverlight player, for maximum ability to ensure video is displayed.

The bad:

  • It was quite slow in my testing. The lag time between when an embedded <video> tag was detected and the video was ready to play, was extremely noticeable. It’s likely also due to loading up and then realize it needs to load a Flash or Silverlight player.
  • It didn’t handle dynamic changes very well. I think this could be solved by integrating it as a jQuery UI Widget as opposed to essentially just a basic wrapper routine.


What initially impressed me with Flowplayer was the promise it showed for extending the base display with html overlays to help add contextual information to the video. Then I started looking over the site, and noticed that the documentation is absolutely top notch. These guys aren’t playing around. Very impressive.

The good:

  • The documentation. Oh my … word.
  • The API. Not only is it very accessible and well thought out, it’s throughly documented.
  • Playlists. It’s something I missed when playing with MediaElement.js.
  • Have I mentioned that Flowplayer is well documented.

The bad:

  • It’s huge. At roughly two times the size of JW Player, Flowplayer is the heavyweight of the bunch, which slows down that all important first page-load impression.
  • There’s some weirdness in it’s playlist system. When you push in a new playlist, the “cover image” isn’t loaded until you run play, which adds more delay between when the user initiates an action and when the player is where I will call “ready”.

JW Player

JW Player is now on version 5.2. I first used it somewhere back in version 3, and as a disclosure, own an unlimited license for both versions 3 and 4. I have been consistently impressed by the flexibility of the player, and it’s ability to handle whatever I throw at it… once you figure out how to tell it what it wants to know.

The good:

  • Flexibility is the name of the game.
  • It did everything I wanted it to, in a way that I could live with.
  • It was lightweight and the quickest to go from page load to presentation.

The bad:

  • The documentation could use some work. Instead of having answers at my finger tips, I had to search for them. Even for pretty basic things.
  • Some more descriptive errors might be nice, as opposed to things simply not working.

In the end, JW Player worked best for my purposes on this project, but every project is different, and I hope this helps some of you save some time.

Using JavaScript Responsibly

Since we’ve started the conversation, let’s take a step back and talk about something a little less fun, but just as important: when is it okay to require JavaScript use?

My hard and fast rule is that anywhere a login is required to reach, you can require JavaScript. If it’s publicly accessible, however, you should do everything possible to avoid requiring JavaScript. It takes more work to have a JavaScript and non-JavaScript version, but it makes sure your site remains accessible.

How to add jQuery to your Symfony project, part 1.

The simplest way, hands down, is to simply include the sfJqueryReloadedPlugin in your project. This also enables you to include the sfAdminDashPlugin which makes for easy navigation and a nice login screen for your back-end systems.

However, the problem with jQuery Reloaded, is that it is both old, and for our purposes, incomplete.

Since the last update to jQuery Reloaded, jQuery has progressed to version 1.4.2 (from 1.3.2), and more importantly jQuery UI has upgraded to 1.8.2 (from 1.7.3) and added some very nice and easy pieces we can use in our quest to simplify some of the widgets users are commonly presented.

The other problem we will run into with jQuery Reloaded, is that it doesn’t provide the CSS half of the jQuery UI library, meaning we would not be able to see any widgets we used properly.

So, with all this in mind, you now understand why in Part 2, I will be showing you how to roll your own jQuery plugin for Symfony.