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.
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.
The player has upgraded its internal integration with YouTube to their latest "chromeless" player. This impacts JW Player users in a couple of ways:
This release also consists of some additional enhancements:
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.
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.
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.
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 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.
This table sums up support for the various streaming methods across devices and servers.
|Devices||Progressive Download||RTMP/RTSP Streaming||Adaptive HTTP Streaming|
|Adobe Flash Player||MP4, FLV||RTMP||HLS, Zeri, Smooth|
|HTML5 (Safari & IE9)||MP4||-||-|
|HTML5 (Firefox & Chrome)||WebM||-||-|
|Android Devices||MP4, WebM||RTSP||HLS (as of 3.0)|
|CDNs (e.g. CloudFront)||MP4, FLV, WebM||RTMP||HLS|
|Web Servers (e.g. S3)||MP4, FLV, WebM||-||HLS|
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.
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.
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.
<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?
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:
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.
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!
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.