Category: Streaming Media Technology Tips

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.

Dipping into Live Mobile Streaming

By Larry B, May 18, 2010

For an upcoming university commencement, I’ve been looking into doing live streaming in H.264/Flash, as well as http streaming to Apple iPhone/iPad/iPod devices (herein referred to as iP* devices) and rtsp streaming to Droids and Blackberrys. It’s been an experience piecing it all together, and I’ll be writing about some of the surprises and pitfalls as we figure out how to best do it.

In a nutshell, we’re using Limelight Networks’ Flash Media Server 3.5 for delivery to browsers on PCs and Macs. For mobile streaming, I provisioned and started up an instance of Wowza on Amazon EC2. One stream in (or several, for multiple bitrate support) via RTMP, and Wowza delivers in all the right formats – whether it’s chunked HTTP (Apple devices), RTSP (Droids and Blackberrys), or RTMP (Flash).  Setting that up involved an awful lot of moving parts, but half a day later, it was up and running and has been flawless in testing. We’ve been streaming multiple bitrates (100kbps, 500kbps, 900kbps) from Adobe Flash Media Live Encoder on a PC, as well as from Telestream Wirecast on a Mac.

We’ve developed a page that uses the JW Player (Flash) as the default, and falls back to HTML5 if it’s an iP* device, or provides an rtsp:// link if it’s a Droid or a Blackberry. Yes…Flash is the default for all browsers that will allow it, as it provides a uniform experience for all users, and a single thing to worry about from a user-support perspective.

What’s been interesting to me is how quickly it all went together. In a couple of days, starting with no deep mobile experience, we’ve provisioned infrastructure in the cloud, configured it, and are up and running with live Flash and mobile streaming for short money. More details to follow in the coming days…

Flash crossdomain security

By Larry B, May 2, 2010

Flash security constraints can prevent a SWF hosted on one domain from reading data hosted on another domain. Users trying out the SlideSync and SlideScroller plugins might encounter this issue if the XML data file that contains the slide URLs and timing is on a different website from the one that hosts the JW FLV Player itself.

The solution is to add a crossdomain.xml file to the root directory of the web server that hosts the XML file. There’s official Adobe docs on crossdomain policy files, and here’s a pretty good tutorial on crossdomain.xml files.

In short, you create this simple file using any text editor, and set up a rule describing which other sites may access data hosted on the site where the crossdomain.xml file lives.

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <allow-access-from domain="*.learningapi.com" />
</cross-domain-policy>

sbs!

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.