Blog Archives: April 2011

JW Player 5.6 Adds Support for Audio Files in HTML5, plus YouTube HD

by Pablo Schklowsky on 2011-04-28 17:16

While the JW Player version 5.5 release added some exciting new developer capabilities, JW Player 5.6 focuses on bringing publishers a few useful features.

Support for Audio Files in HTML5

Ever since the JW Player introduced support for HTML5 mode back in JW 5.3, we've had a lot of feedback requesting that audio files be playable in HTML5 mode as well. With 5.6, you can now play your MP3, AAC or Ogg Vorbis audio files in HTML5 mode. Just remember that the player relies on each browser's support for any particular media format.

Better YouTube Integration, Including YouTube HD

The player has upgraded its internal integration with YouTube to their latest "chromeless" player. This impacts JW Player users in a couple of ways:

• YouTube HD support — One of the first things you'll notice is that YouTube videos will automatically switch to the HD version if it's available (and if the player window is large enough to accommodate it). If your player window is smaller than the HD version, don't worry - the player will automatically switch to HD in fullscreen mode.
• No more yt.swf — Previous versions of the JW Player included a little helper file, yt.swf. This file is no longer needed; as of JW5.6, the player's YouTube integration is now internal.
• Ad-supported content — As we pointed out in a recent blog post, YouTube has begun blocking certain content that they or their partners consider monetizable. JW 5.6 includes support for ads placed by YouTube over this content, allowing it to be embedded on your site.

This release also consists of some additional enhancements:

• Better tabbing support for browsers and screen readers
• Ability for plugins and JavaScript to show / hide the dock and controlbar
• Ability to pass complete JavaScript (JSON) objects into the player via the JW Embedder
• New onSeek event in the JavaScript API

For a detailed list of tickets, please see this list.

You can download the JW Player 5.6 for Flash and HTML5 here. As always, feel free to post your feedback in the comments section directly below.

Comments (9)   Tweet   Share

What is Video Streaming?

by Jeroen Wijering on 2011-04-27 02:34

With all of the buzz around HTML5 and the iPad, there's been a lot of talk about the technologies underlying digital video. Besides the inevitable codecs (H264 & VP8), experts are discussing video delivery mechanisms, using indecipherable acronyms like RTMP, CDN and HLS. This blog post will give an overview of the various video streaming methods in plain English and bring the all-round developer and publisher up to date.

In a nutshell, there are three widely used ways to stream a video: Progressive Download, RTMP/RTSP Streaming, and Adaptive HTTP Streaming. We'll look at the three in detail here, describing their pros, cons, and various technologies that support each.

Note: more streaming methods (like MultiCast or Peer 2 Peer) exist, but are of little use to the regular publisher. They are not widely adopted and/or only useful in specific situations.

Progressive Download

Progressive Download is the most widely used video delivery method by far (in part because it's what YouTube uses). It's also easiest to implement: just put a video on your webserver and point your player to the URL. Once a user hits play, the player immediately starts downloading the file. The player will start video playback as soon as it has enough data to do so, but it will continue to download until it has received the whole file (hence the progressive).

Progressive Download is supported by Flash, HTML5 browsers, the iPad/iPhone and Android. On the server side, every regular webhoster supports downloads, as does every CDN (Content Delivery Network; webhosters that special in large-scale delivery). In most cases (Flash needs a small server module), it is possible to seek in a player to a not-yet-downloaded part of the video. At that point, the player re-downloads the video, starting at the seek offset instead of at the beginning. We call that feature pseudo-streaming.

The simplicity of Progressive Download also has its downsides. For one, bandwidth is wasted on data downloaded but not watched. Consider a user watching a ten minute video. They may leave the page after having watched only one minute of the video, but at that point the other nine minutes have already been downloaded. This means that the publisher has paid to transfer nine times as much data as the user actually watched - an expensive proposition on a large scale.

Another downside is the inability to change the quality of the video mid-stream: once the download starts, the video quality is locked. After switching a player to fullscreen, you generally see a blurry video, because it was intended to be watched at a much smaller size. Or, when you watch video on an iPad, your connection may switch from WiFi to 3G. Playback then stutters, because the download speeds are much lower on 3G.

In sum, Progressive Download works fine for short clips (a few minutes). For longer videos, the downsides start to impact playback too much. Plus, live streaming is not possible, as there's no downloadable file.

RTSP/RTMP Streaming

Because of the downsides of Progressive Download, RTMP/RTSP Streaming is widely used by professional media organizations like Hulu. This method uses specialized webservers that only deliver the frames of a video the user is currently watching. No data is downloaded in advance and data a user has seen is immediately discarded.

The most widely solution is used is RTMP (Real Time Messaging Protocol), the streaming protocol of Flash. It is supported by servers such as FMS and Wowza and most CDNs (but not by regular webhosters). HTML5 does not include a dedicated streaming protocol, nor does the iPad/iPhone. Android has support, for RTSP (Real Time Streaming Protocol). Unfortunately, RTSP is not widely supported by servers and CDNs.

This lack of support, especially on the server side, is the biggest drawback of RTMP/RTSP Streaming. Most publishers do not want to maintain expensive, dedicated servers to stream their videos. Additionally, the dedicated protocols (RTMP and RTSP) are often blocked by corporate firewalls.

On the plus side, RTMP streaming can change video quality mid-stream. This allows for optimal playback quality in the fullscreen and WiFi/3G scenarios described above. However, if the connection speed drops below the minimum bandwidth needed for the video, playback will be continuously interrupted. Unlike progressive download, users cannot pause a video and wait for enough data to download to ensure smooth playback.

In sum, RTMP/RTSP Streaming works great even for long-form or live video. It has specific server and protocol requirements, which makes it less accessible and adds significant complexity and cost as compared to Progressive Download.

Adaptive HTTP Streaming

Adaptive HTTP Streaming is a fairly new streaming format. It attempts to join the merits of RTMP/RTSP Streaming (bandwidth efficiency, quality switching) with those of Progressive Download (no special servers or protocol needed). Adaptive HTTP Streaming works by storing your videos on the server in small fragments (a few seconds each). The player then glues these fragments together into a continuous stream.

At present, Adaptive HTTP Streaming is supported by both Flash and the iPad/iPhone. Android supports it as of version 3 and support in HTML5 is currently under development. Since Adaptive HTTP Streaming leverages standard webservers, it is supported by webhosters and CDNs alike.

Although Adaptive HTTP Streaming eliminates many of the downsides of RTMP/RTSP Streaming and Progressive Download, it still has issues of its own, the biggest being the lack of standardization. Because it is a new technology, there is no single, widely used implementation. The most popular is currently Apple's HLS (HTTP Live Streaming), which is supported by the iPad/iPhone and Android 3.0. However, both Adobe and Microsoft have competing offerings (Zeri & Smooth) and the MPEG consortium is working on a standard named DASH.

It's also worth noting that none of the Adaptive HTTP Streaming implementations work with regular MP4 files. They all require your files to be converted from a regular MP4 into a specific fragmented format. Apple, Microsoft and Adobe each supply a tool for this, but support for these formats doesn't exist in regular video editors and transcoding tools (yet).

In summary, while Adaptive HTTP Streaming will likely become the single video streaming method over time, the technology is still fragmented (no pun intended) and ecosystem support is only beginning to arrive.

Summary: Streaming Support

This table sums up support for the various streaming methods across devices and servers.

Comments (23)   Tweet   Share

Publish Your Videos to Facebook with a JW Player

by Zachary Ozer on 2011-04-13 12:25

Over the past few months, you may have noticed that an increasing number of items in your Facebook News Feed had a play icon in the bottom left hand corner, like so:

This is because Facebook recently opened the News Feed to third parties, allowing individuals to watch videos from all over the Internet without ever leaving Facebook. While getting this to work requires making some minor modifications to your website, publishers have been quick to implement the changes because of the number of video views Facebook can help drive (especially when a video goes viral).

In this blog post, we'll describe how publishers can use the JW Player with the Facebook News Feed and enable viewers to have the same experience regardless of where they're watching it.

What You'll Need

• A video, audio file, or any other piece of content that is playable by the JW Player
• A copy of the JW Player SWF, hosted on your web server
• A web page for your content
• This document (pretty meta, huh?)

Getting all of this to work is pretty simple, but it can be difficult to manage if you've got a large library of content. Additionally, Facebook does not store a copy of the content or player, so they will be loaded from your server every time they are watched on Facebook. If you're worried about management or your ability to handle the load when your video goes viral, it's worth taking a look at services like LongTail.tv and Bits on the Run, both of which support this type of Facebook integration natively.

Updating Your Site

Whenever someone publishes a post with a link to their News Feed, Facebook scans that page for metadata about that page. By including some specific metadata in the <head> of your page, you can instruct Facebook to embed your JW Player with your content in the News Feed. However, this also means that you'll need a unique web page with this metadata for each piece of content, which can become quite difficult to manage if you're not using a CMS like Wordpress or Drupal.

When scanning a page, Facebook examines the <meta> tags. Specifically, it looks at Open Graph tags - those with with an og prefix to the property attribute - and uses the data contained in the content attribute.

An Example

<html>
  <head>
    <meta property="og:type" content="movie" /> 
    <meta property="og:video:height" content="260" /> 
    <meta property="og:video:width" content="420" /> 
    <meta property="og:video:type" content="application/x-shockwave-flash" />
    <meta property="og:title" content="Big Buck Bunny" /> 
    <meta property="og:description" content="Big Buck Bunny is a short animated film by the Blender Institute, part of the Blender Foundation." />
    <meta property="og:image" content="http://www.example.com/bunny.png" />
    <meta property="og:video" content="http://www.example.com/jwplayer/player.swf?file=http%3A%2F%2Fwww.example.com%2Fbunny.flv&autostart=true" /> 
  </head>
  <body>
    …
  </body>
</html>

So what do each of these tags mean?

• og:type - The type of content described by this page, should always be "movie".
• og:video:height / og:video:width - the height and width (in pixels) of your video player will occupy within the news feed.
• og:video:type - The type of video playback you'd like to use, should always be "application/x-shockwave-flash".
• og:title / og:description - the title and description of your video. Note that the title attribute is different from the HTML <title> tag, and it will not show up in the browser's title bar.
• og:image - the poster image. This is what will be displayed on the viewer's wall with the play button over it.
• og:video - the URL to your JW Player, with the configuration passed in as part of the URL string.

Constructing the Video String

Coming up with a usable og:video tag is a bit of a challenge. Since many of our plugins require similar configuration, we've got some documentation that should come in handy. However, you can also follow these steps to build the string:

• Start with the absolute path to your JW Player (ie, "http://www.example.com/jwplayer/player.swf").
• Next, add a "?". Everything after this will be interpreted as player configuration, and ensures that your web server will serve up your video player.
• For each configuration option you'd like to specify, add the name of the configuration option, then a "=", and finally the URL-encoded version of the value you wish to specify (ie "file=http%3A%2F%2Fwww.example.com%2Fbunny.flv&autostart=true"). Be sure to separate each configuration option with a "&".

As always, you'll need to make sure that you're using absolute paths to reference your content and skins. Also, you'll need to make sure that you have the proper cross-domain security restrictions in place.

Posting to Facebook

Thanks to all of your hard work, posting into Facebook is a snap! Simply drop your into the share box, like so:

You'll notice that there's no play button in the preview image. Once you hit the share button, the play button will be added and your content will be posted for the whole world to view and enjoy within their News Feed!

Security Limitations (HTTPS)

Recently, Facebook has received some bad press because the site's login is not encrypted, making it easy for someone using the same WiFi as you to take over your Facebook account. To get around this, Facebook began offering the option to use a secure version of the site (HTTPS). When using this version of the site, Facebook does not always allow you to view content within the News Feed and may link you off to the original source of the content to view it. This is because most sites do not serve up their content via HTTPS, and loading standard HTTP content in an HTTPS site will result in an aggravating mixed content warning in all browsers.

Comments (182)   Tweet   Share