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.
- 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.
- 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 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.
- 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 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.
- 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 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.