Category: Web and Software Development

Variable Speed Playback – HTML5 Video Feature

comments Comments Off
By Larry B, April 6, 2012
One of the most desired features for educational video content - particularly recorded lecture content - is the ability to speed up playback to 1.2x or 1.4x normal speed. Now, you can easily add this feature to your video website, with a few caveats.

When you increase playback speed, it turns out that it's still quite listenable, and the quicker pace can even enhance the experience. Chit chat, pauses, um's and ah's and other delays that slip by unnoticed when you're live in the room face-to-face with the speaker become unbearable time-wasters when you're watching a recording on your own time.

There used to be two options for enabling this. On the client side, third-party products installed directly by end users, like Encounce's MySpeed plugin, were the way to do it.

On the server side, you could encode the video with the faster timeline baked in, and let the user switch streams at will. Bloggingheads.tv uses this method on most of its videos.

But now, HTML5 video playback offers the same capability (at least on some browsers). Let's take a look at an example. (You'll need to use Chrome, Safari, or IE9 for this example to work - Firefox (at least as of version 8) does not yet support this.)

The key is the <video> element's playbackRate property. Normal playback speed is expressed as a floating point number: 1.0. Accordingly, 2.0 is double speed, 0.5 is half speed.

Here's a code sample for the links above the video shown below:
<script type="text/javascript">

function speed(x){
        var myVid=document.getElementById("streamDiv_video");
	myVid.playbackRate=x;
	$('#pbrate').html(x);
}
</script>
...and then the HTML...
        <a href="javascript:speed(0.5)">.5x</a>
	<a href="javascript:speed(1.0)">1x</a>
	<a href="javascript:speed(1.2)">1.2x</a>
Now the example...
.5x 1x 1.2x 1.4x 2x
Playing at 1x
If you're using Firefox, you won't see video. Firefox cannot play H.264 video in HTML5. Encoding in WebM would have made the video play, but since Firefox does not yet support the playbackRate property, this demo still would not have worked.
Video: Just Another Day, NASA JPL.

There are advantages and disadvantages to each method:
MethodAdvantagesDisadvantages
Client-side PluginLocal install for user - no effort on content provider's part.Can't offer as universal feature of your site, does not work well with RTMP Flash streaming - HTTP only.
Encoding with timeline baked inWorks with RTMP, Flash, any browserExtra encoding for site owner, custom code to switch streams seamlessly, can't do progressive download, requires streaming (or pseudo-streaming) protocol that provides random access into video
HTML5 playbackRateLightweight to implement, just some Javascript on the page, works with progressive downloadWorks only with HTTP delivery, works only on certain browsers
The W3C has a good HTML5 Video property and event demo tool where you can manipulate playbackRate and other properties, and see the resulting events as they happen.

HTML5/Flash Video Player Comparison

By Larry B, July 21, 2011

screengrabHere’s a nice one-stop-shop for comparing HTML5-capable video players: VideoSWS, (where SWS apparently means, “See What Sucks”).

The chart provides a rough view of player capabilities. but clicking the names of each player brings you to a working example of the player. Not extensive analysis of each, but great for a quick survey of what’s out there for embeddable players.

Thanks are due to Philip Bräunlich and Gerrit van Aaken for creating this!

HTML5 Video – It’s a long way ’til JQuery

By Larry B, September 14, 2010
The hype around HTML5 video is finally getting pierced with a dose of reality.  That reality, as far as I can see, is that HTML5 is a nascent idea of something that will undoubtedly be useful some day. But at the moment, for many of us publishing video to the 'Net, it's more of a problem than a solution. Some great thoughts on the issue have come from Jan Ozer at the Streaming Learning Center, and technical analyst extraordinare at streamingmedia.com. In his article, The Five Key Myths About HTML5, Jan points out that in practice, supporting HTML5 means encoding multiple formats of everything, an inability to do live streaming or on-demand stremaing using a true streaming protocol, working around numerous browser incompatibilities, and no adaptive/dynamic streaming. He summarizes:
  • No major media sitepresents HTML5 as their primary viewing optionHTML5-compatible browser penetration is low, and will continue to be well into the future
  • Though HTML5 is great for low volume video playback, it lacks many critical features currently available in plug-in based technologies
  • Full HTML5 support will require 2 or 3 times the encoding chores of Flash support
Longtail Video's Jeroen Wijering, maker of the popular JW FLV Player and JW Silverlight Player wrote in HTML5 Video: Not Quite There Yet:
The video tag is still in its infancy and misses certain core functionalities. As developers demand these features, browser vendors are tempted to implement incompatible solutions instead of agreeing upon standards. These hasty developments, already underway, are setting HTML video up for the same chaos  as HTML styling in the pre-CSS era.
We remember those days...multiple coding and testing for every possible brower combination, and any web application with an interesting, innovative, or especially responsive UI (using CSS and DOM-manipulation) was fragile and expensive to maintain. Eventually, standards got better and better-supported, and libraries like ExtJS and JQuery provided abstraction that made authoring powerful and reliable applications easier.  Things in a web app that used to be done with a Flash or Java applet UI are now routinely done using these Javascript/CSS libraries.

So there's hope for HTML5 video, but it's not there yet and it won't be there for years. The hype around HTML5 isn't matched by the reality - which is that it's a pain that complicates our work in streaming; and that Flash or Silverlight are going to be better choices for most purposes for some time to come.

In the direction of standard libraries to make life easier for the streaming publisher, Longtail Video has just released a Beta of their JW Player 5.3, which seamlessly integrates Flash and HTML5 support.  It's got a whole new API for embedding and Javascript event handling; and it lets you set the HTML5 failover in either or two options:

  1. Use HTML5 wherever it's supported, otherwise failover to Flash
  2. Use Flash unless it's not supported, then failover to HTLM5.
I'll be testing the 5.3 Beta player over the next few days and will post my impressions.

New Hosting Provider – So Far, Excellence

By Larry B, May 18, 2010

There’s few things as delightful as being surprised by outstanding customer service and perfect execution of something difficult. Specifically, I’ve been wanting to move my website to a new hosting provider for a while now. My old host was becoming increasingly unreliable, particularly with respect to email. But the pain of switching hosts creates a powerful inertia – it’s easier, for a while, to deal with the problems than it is to move everything. I have a WordPress installation, MovableType, several busy email accounts using IMAP, a few databases, etc. I just didn’t have the time to deal with it.

GreenGeeks logoWhich leads to my experience with GreenGeeks hosting. I found them doing the usual Googling around and reading reviews. I liked the price. I liked the green idea of buying wind credits to offset power use (although how much of that represents a real net effect on the environment, I have no idea. It, at least, feels like doing something good.) I loved the idea that they will do your site migration for you.

I had absolutely no expectation that they would be able to migrate everything. I expected to spend some hours/days tweaking this and that to get it all up and running as on my original host. But just moving the files across and setting up users, etc….that’s helpful, anyway, right?

Well, it was perfect. There were a few emails as they asked questions and came to understand my environment, and then two days later I get an email that says “It’s ready.” And darned if it wasn’t. WordPress, MovableType, all my symlinks and apache config, all the email accounts with all the content intact. My migration effort consisted of updating my domain registrar’s DNS record. Period.

I can’t say much yet about reliability of the service (although it’s been 100% so far!), but I can say that the migration service and the general customer service I’ve received in my three days on GreenGeeks hosting has been outstanding. AFter starting to write this post I realized that they have an affiliate program, so yes, I signed up and these are affiliate links. But that was an afterthought. My enthusiasm for the service, and my delight at how easy it was to switch, is genuine.

Synchronized Slides for the JW FLV Player – Two New Plugins

By Larry B, April 6, 2010

SlideSync screenshotFor years I’ve been hearing and reading about demand for a simple synchronized slides plugin for the JW Flash Video player. Sure, you can do it with some Javascript: add event listeners to track the play-head position and use that to trigger image loads in a separate DIV. But that requires page scripting and introduces dependencies that might not always be do-able.

But I always thought there oughtta be a simpler way. So I made one. Honestly, I didn’t know if it was possible using the JW Plugin API, and while I’m a pretty good Java/Web programmer, I’m definitely not a Flash/ActionScript ace. So I decided to give it a try as a learning experience. The result is two plugins for the JW FLV Player: SlideSync and SlideScroller. These are free for commercial and non-commercial use.

You can see an example of the SlideSync and SlideScroller plugins in action, or look at documentation of the options and parameters, or go to Longtail Video’s plugin pages for the SlideSync and SlideScroller plugins.

There’s a lot of room for improvement and growth in this. It’s really a first-effort, but should be useful anyway in some cases. There are still reasons to use the Javascript event-listener model as well, which offers lots of flexibility and control you won’t get from the this plugin. But for simplicity, this is a good start. Feedback is welcome. Improvements welcome, too! The source is linked on the documentation page.

Testing Adaptive Streaming by Controlling Bandwidth

By Larry B, March 17, 2010

In the course of researching my article on Dynamic Streaming in Flash, I ended up doing way more testing than I’d initially intended. But things didn’t work the way I expected right away, and being the way I am (foolish? glutton for punishment?), I had to find out why.

There’ll be more on that in the article when it comes out on streamingmedia.com, but for now, I wanted to make a note about how to simulate fluctuating bandwidth conditions.

On Windows, Netlimiter 3 Lite works OK, especially if you’re just doing bandwidth detection to select the appropriate stream at startup. Shunra VE Desktop seemed to create more realistic test conditions for fluctuating bandwidth and stream-switching during playback, an impression that was validated by colleagues I spoke with. At $850 a pop, it certainly ought to be better than the $20 NetLimiter.

But on the Mac, it all worked for free. It’s already built in to the OS’s Unix roots.  It’s in the ipfw command.  You set it up by creating filters with bandwidth limits, then associating those filters with the ports you want limited.  Here’s how to set up a bandwidth limiter for testing streaming over all ports. Note that if you’re not logged in as root, you will need to use sudo to run these:

sudo ipfw pipe 1 config bw 400kbps
sudo ipfw add 10 pipe 1 tcp from any to me
sudo ipfw add 11 pipe 1 tcp from any to me

Change it at will by issuing the pipe command again…

sudo ipfw pipe 1 config bw 1400kbps

Or remove the filters like this…

sudo ipfw delete 10
sudo ipfw delete 11

You can also introduce simulated network latency, control outbound bandwidth separately from inbound, and control bandwidth to or from a single IP address or subnet.  There’s great documentation at Luigi Rizzo’s Dummynet site.  Thanks also to Ask Bjorn Hansen for his mini-tutorial on this.