Entries By pablo schklowsky

What's new in HTML5: The Track Element

by Pablo Schklowsky on 2012-07-12 13:17

One of the more exciting developments in HTML5 video is the inclusion of the track element in the newest versions of the desktop browsers. In addition to bringing captioning and subtitle support to HTML5 video, the invisible track element allows publishers to attach a rich array of textual metadata to their videos. In this blog post, we'll look at the different types of tracks that can be used in conjunction with the <video> tag.

Browser Support

First, the bad news. The track element is extremely new, and browser support is growing, but limited. The current version of Chrome supports it, but the functionality must be enabled via a configuration option (go to chrome://flags, Enable <track> element). Internet Explorer 10, which is available in the Windows 8 developer preview, also has a working implementation. Mozilla is working on it for Firefox, but no timetable has been given for when it will be complete. In short, the track element is future tech, but luckily we can begin working with it today.

WebVTT: A New Format for Text Tracks

The web standards community has developed a new standard, called WebVTT (Web Video Text Tracks), which will be supported by all browsers implementing the track element. WebVTT provides a simple, extensible, and human-readable format on which to build text tracks. Although it is based on SRT (a popular subtitling format), a few tweaks have been made to the format. For content creators who already have subtitles in SRT, a no-frills converter is available.

Here's a very simple example of a WebVTT file:

In this example, the file contains two timed segments, called cues. These cues can come in many flavors, up to and including full HTML.

Here's how to embed a video with a text track:

One Element, Many Uses

One of the reasons the track element is so captivating is its versatility. It can be used to make video accessible, to organize content that occurs within a video, to enable more robust interactions, and much more. This type is specified in the track element by setting the kind attribute. There are currently five different values the kind attribute can be set to: subtitles, captions, descriptions, chapters and metadata.

Accessibility: Captions, Subtitles and Descriptions

Let's take a quick look at the first three text track types, subtitles, captions and descriptions. On the surface, they may seem similar, but they actually serve different purposes.

• Subtitles are what you might expect to see while watching a foreign-language film — they're a transcription or translation of the video's dialogue.
• Captions, on the other hand are designed for viewers who can't hear the audio of the video, and include descriptions of non-dialogue sound. For example, if a character in a video slams a door off-camera, the captions would include something like [door slams]. Both subtitles and captions are displayed by the browsers as text overlays on top of the playing video.
• Descriptions are not displayed visually, but are rather spoken out loud by a screen reader, benefitting viewers who can't see the video. Not surprisingly, descriptions describe what's happening visually in the scene.

All three of these kinds of tracks combine to make a video accessible to more viewers, and, as we'll discuss later, to search engines as well.

Chapters: Navigating the Video

One of the more difficult problems to solve in web video has been how to index and recall discrete segments of content within a longer video. This is especially true when the different sub-segments pertain to dramatically different subjects. Publishers are either required to break up the video into more manageble chunks and tag the smaller chunks appropriately, or use complicated tools or scripts to synchronize the video player with an external index.

Using chapter text tracks, publishers can organize their long-form content in a WebVTT file which is embedded alongside of the video. Although current browser implementations do not yet do anything with chapter tracks, one can safely assume that they will do so in the future. In the meantime, developers can access the information contained in the chapters track via JavaScript and use it to build their own chapter interfaces.

Metadata

The track element supports one additional type of text track, metadata, which is at the same time vague and extremely powerful. Metadata tracks allow developers to synchronize any information they wish with time points within a video. When the time point described in the cue is reached, a JavaScript event will fire, and the text contained in the cue is passed to the script. A simple example could be latitude and longitude coordinates which correspond to certain time points within a video. A script could listen for these cues, and update a map with the current coordinates as they change in the video.

The possibile use cases for metadata tracks are virtually limitless, and we'll explore some of these in more detail in a future post.

Making Video Content More Searchable

We've discussed how the text tracks are interpreted by the browser and displayed to a viewer, but this only scratches the surface of what's possible once videos are annotated by text tracks. Search engines can use the contextual information contained in the tracks to correlate search queries to specific points within in a video. Because the tracks are separated logically, a search engine can prioritize results based on the length of a related segment, the frequency with which the search term appears in the video, and even whether the subject of the search term appears visually in the scene, regardless of whether or not the word itself is spoken.

Furthermore, a search engine can make use of translation engines to open up search results to users who speak different languages from the language used in the source video. The subtitle tracks themselves could theoretically also be translated automatically by the browser. Although a human translation is obviously preferable, this approach allows many more viewers to engage with the content at very little additional cost.

Captions in the JW Player

No discussion (at least on this blog) would be complete without a note on support in the JW Player for the topic at hand. Although the current player can display SRT captions through the Captions plugin, this support will become much more tightly integrated into the upcoming version 6.0 of the JW Player, which will support WebVTT as well. Here's a sneak peak at what captions selection will look like in the new player:

Where Do We Go From Here?

As we've seen, text tracks aren't just for subtitles - there's a virtually limitless range of applications for them. Over the next few weeks, we'll be posting demos and examples showing the track element in action. I'll also be presenting on the track element at this year's DevCon5 conference later this month. [Update: slides and demos here.] So stay tuned!

Comments (10)   Tweet   Share

Using the Browsers' New HTML5 Fullscreen Capabilities

by Pablo Schklowsky on 2012-05-24 10:25

One of the killer features for HTML5 video is native browser fullscreen support. Without it, a viewer watching video through HTML5 is limited to seeing the video within the browser window, which is clearly not an immersive experience. In our latest State of HTML5 Video report, we reported that 50% of the browsers people are using now support fullscreen features natively. Some sites you probably currently use (Facebook, for one, in their image galleries) are already using the native browser fullscreen APIs. Here at LongTail, we are bringing this functionality into the next version of the JW Player, but in the meantime, I'll walk you through the new feature, and show you how easy it is to implement.

Note: This article is aimed at website developers who are comfortable editing HTML and CSS, and a little bit of JavaScript

What is Native Fullscreen Anyway?

Native fullscreen means that the browser uses your entire monitor to display content. This means that no other windows are visible, and the browser's menu, tabs, and other elements go away. Compare these two screenshots:

Step 0: Use a Fullscreen Enabled Browser

None of this new functionality will work if your browser doesn't support it. Currently only Google Chrome version 15+, Firefox 10+ and Safari 5.1+ support fullscreen mode. Make sure you have the latest versions of those browsers for these examples to work!

Upcoming versions of the major browsers will all include fullsceen support in some form. Internet Explorer 10 (currently in beta) will provide support, and Opera (who were involved in writing the fullscreen draft spec) are likely not far behind.

Step 1: Decide What to Fullscreen

First, you'll need to create a bit of HTML, and decide what element to blow up to fullscreen when the time comes. Here's a little bit of code containing an image which we'll eventually take to full-screen.

Click Me To Go Fullscreen! (not yet)

<div class="example">
  <img class="video_player" src="image.jpg"></img>
  <button>Click Me To Go Fullscreen! (not yet)</button>
</div>

Step 2: Tell the Browser To Go Fullscreen

You'll notice that in the above code, our fullscreen button doesn't do anything yet. We'll need to write some JavaScript which will take the image into fullscreen mode. I'll explain what everything does in the code itself.

Click Me To Go Fullscreen! (For real)

<script type="text/javascript">
  function goFullscreen(id) {
    // Get the element that we want to take into fullscreen mode
    var element = document.getElementById(id);
    
    // These function will not exist in the browsers that don't support fullscreen mode yet, 
    // so we'll have to check to see if they're available before calling them.
    
    if (element.mozRequestFullScreen) {
      // This is how to go into fullscren mode in Firefox
      // Note the "moz" prefix, which is short for Mozilla.
      element.mozRequestFullScreen();
    } else if (element.webkitRequestFullScreen) {
      // This is how to go into fullscreen mode in Chrome and Safari
      // Both of those browsers are based on the Webkit project, hence the same prefix.
      element.webkitRequestFullScreen();
   }
   // Hooray, now we're in fullscreen mode!
  }
</script>

<img class="video_player" src="image.jpg" id="player"></img>
<button onclick="goFullscreen('player'); return false">Click Me To Go Fullscreen! (For real)</button>

Step 3: Resize Your Elements

You may have noticed on some browsers (Opera and Chrome) that when you clicked on the fullscreen button that the video player was centered in the middle of a big black screen. That's because by default, fullscreen mode doesn't resize your elements for you. Luckily, there's a simple bit of CSS which will allow you to specify how you want your elements to appear in fullscreen mode. It's called something different in each browser, but in Chrome, it's a CSS pseudo-class called :-webkit-full-screen. In Firefox, it's called :-moz-full-screen. We want our player example to strech all the way across the screen, so that's what we'll do.

Click Me To Go Fullscreen! (All the way)

<style type="text/css">
  .player:-webkit-full-screen {
    width: 100%;
    height: 100%;
  }
  .player:-moz-full-screen {
    width: 100%;
    height: 100%;
  }
</style>
<img class="video_player" src="image.jpg" id="player3"></img>
<button onclick="goFullscreen('player');">Click Me To Go Fullscreen! (All the way)</button>

Fullsceen and <iframe> - a technical note

While you can take pretty much any element and take it to fullscreen mode, <iframe> elements are a bit trickier. You'll need to set the "allowFullScreen" property on the tag itself, which allows the contents to be taken into fullscreen mode.

<iframe src="iframe_src.html" width="400" height="300" allowFullScreen></iframe>

Where Do We Go From Here?

You can make all sorts of changes to your fullscreen elements once you're in fullscreen mode, either using CSS or using some more in-depth JavaScript code. For example, if you had a text overlay that you wanted to make visile in fullscreen mode, you could show it using the -full-screen CSS pseudo class (remember, you need to replicate this property for each browser). The rest is up to your imagination!

Comments (21)   Tweet   Share

How to Stream Live Video From Your iPhone to the JW Player

by Pablo Schklowsky on 2012-05-03 18:26

A few people have asked us if they can stream live video from their iPhones directly to the JW Player. If you're willing to install and configure a few applications, the answer is yes! This guide will provide step-by-step instructions on how to do it.

This tutorial is broken up into three steps:

Step 1: Set up Your Streaming Server

First, you'll need to download and install Wowza Media Server. They have a free 30-day trial available. Once you've installed Wowza, you'll need to configure your Wowza server, by editing files in the install directory. This is different for each platform, but you should be able to easily find where Wowza has installed its files.

1. Find the applications folder in the Wowza installation folder. By default, there will be nothing there except for a folder called vod. Create a new folder for your live streaming application. We'll call it livu.
   (screenshot)
2. Next, open up the conf folder and create another folder called livu. Then copy the Application.xml file from the conf folder to the livu folder.
   (screenshot)
3. Now open up the Application.xml file. Find the <StreamType> property and change it from default to live.
   (screenshot)
4. Still in Application.xml, find the <PublishMethod> property and change it from digest to none. This will turn off authentication for live stream publishing, so you should only do this for testing purposes.
   (screenshot)
5. Back in the conf folder, open up the file called VHost.xml. You'll need to copy and paste the entire <HostPort> section, so that we can set up the port for our live stream ingestion (RTSP). In the new <HostPort>, edit the <Port> property to read 554.
   (screenshot)
   
   Note: On Mac OS X, you'll need to set this value to a number higher than 1024. This is because ports below 1024 must be opened by processes with admin privileges. For example, to avoid trouble, set the <Port> value to 5544.
6. Now, simply start up your Wowza Media Server. If this is your first time running Wowza, you'll be prompted to enter in your trial license number. When it's started up, make sure your RTSP port (554 or 5544) was successfully enabled.
   (screenshot)

Step 2: Set up Your iPhone to Stream to Wowza

Now that you've got your streaming server set up, it's time to set up your iPhone to stream live video. We're going to use a $2.99 app called Livu, which is specifically designed to work with Wowza Media Server. Grab it by searching for "Livu" in iTunes, or by clicking here. Once you've downloaded the app, here's how to configure it:

1. Open up the configuration menu, and in the Host field, enter the IP address for the computer hosting your Wowza Media Server instance.
2. Under App, enter /livu/iphone. If you named your live streaming application something different in your Wowza setup, use that name here instead of livu.
3. Under Port, enter the port your configured for RTSP ingestion in step 6 of the Wowza setup.
4. If you disabled authentication in step 4, you can leave the User Name and Password fields blank.
5. Once everything's configured, press the Save button.
   (screenshot)
6. The Livu app should now activate your iPhone's camera. Click the icon in the top left to start streaming.
   (screenshot)
7. If you've configured everything properly, a message will display saying "Stream Started." You're now broadcasting!
   (screenshot)

Step 3: Set up the JW Player to Play the Stream

If you've made it this far, the hard part is over. Now all that's left is to configure the JW Player to play your live stream. Here's the embed code you'll need to set up your player:

<div id="player"></div> <script type="text/javascript"> jwplayer('player').setup({ streamer: "rtmp://192.168.0.160/livu", // Replace this with your own IP address file: "iphone" }); </script> That's all there is to it. If you've set everything up correctly, the player will display the live video stream from your iPhone!

(screenshot)

Comments (4)   Tweet   Share

HTML5 Takes the Lead on Android Devices

by Pablo Schklowsky on 2012-02-28 10:30

Even before Adobe's announcement back in November that it would cease supporting Flash on Android devices, it was becoming clear to us at LongTail Video that the JW Player would need to shift its focus on Android devices towards HTML5 mode. We took the first step with the release of the 5.9 player, which now embeds itself in HTML5 mode on all Android devices by default, since our testing has shown that Android is fully capable of playing HTML5 video. But there are several reasons why HTML5 should be the delivery mode of choice on Android, with or without Flash. This blog post will attempt to address a few of them.

Limited Future Support for Flash

This one should be obvious, so we'll get it out of the way. After the current generation of Android devices running Froyo (2.2), Gingerbread (2.3), Honeycomb (3.x) and Ice Cream Sandwich (4.0) are either phased out or upgraded to future Android versions, Flash will no longer be supported in the browser.

Video Player Behavior on Mobile Devices

It is difficult to put forth a general rule for how video players should behave on mobile platforms. In fact, the term "mobile" is itself too general in this context, since viewing a web page containing video is a very different experience depending on whether you are viewing on a smartphone with limited screen real estate, versus watching on a tablet with more room for your fingers to interact with the content.

If you load the JW Player on an Android smartphone in Flash mode, you will get the same version of the player you would have gotten had you loaded it on a desktop browser. However, everything will be scaled to the size of your phone's screen, including all of the button controls. Not only would the buttons be hard to press, but they wouldn't really make sense in the context of watching video on a phone. Conversely, the player's HTML5 mode relies on the phone's own built-in video controls, which are optimized for the screen size. Additionally, HTML5 video will always play in full-screen mode on Android smartphones, which is a much better experience.

Viewing video in a browser on a tablet isn't as cut-and-dry of an issue. The screen is larger, so it is possible to have a usable video playing inside of the page content. This can be done in both Flash and HTML5 modes, so the decision of which to use comes down to performance (despite its reputation, Flash doesn't perform that poorly on most Android devices when it comes to video) and usability (the built-in HTML5 controls are optimized for touchscreens, while the Flash controls would need to be modified to work well on touch devices).

Lastly, we feel that it is important to provide a consistent experience across all mobile devices, not just Android devices. Switching to HTML5 playback for Android means that users on both Android and iOS devices will see the same things:

• Fullscreen-only playback (on phones)
• No overlays on top of the video player while a video is playing
• Built-in touch screen controls

Flash Embedding on Mobile Browsers

One issue we've noticed with Flash for Android is that it "steals" interaction events from the browser. For example, if you're scrolling down a page using the one-finger swipe gesture, and your finger happens to brush over a Flash element on the page, Flash will interpret this as a mouse click. In the case of the JW Player, the player will begin to play, when what you actually wanted to do was scroll down the page. Using native HTML5 elements eliminates this sort of behavior, since those elements distinguish between different types of gestures.

HTTP Live Streaming (HLS)

Beginning with Ice Cream Sandwich, Android devices will support HTTP Live Streaming (HLS), which has become the de facto standard for streaming video over HTTP. This is the same format which is used to stream video content to iOS devices. Unfortunately, HLS is not supported natively in the Flash player, making this another reason to favor HTML5 over Flash on Android. For an explanation of what HLS is and why it's important, check out our blog post on the subject.

Android Support in the JW Player Going Forward

For all of the reasons described above, we feel that it is necessary to focus our Android development efforts on HTML5 and not Flash. Flash mode will still be used as a failover on Android devices which support it; for example, if your player configuration specifies an RTMP stream (which can't be played in HTML5 mode), the Flash player will still be used. And if you disagree with our decision, you can still specify Flash as your primary renderer by setting the modes block in your player configuration. But we think you'll find that for Android, HTML5 is the best way to go.

Comments (4)   Tweet   Share

HTML5 Video Ads: Coming To a Mobile Device Near You

by Pablo Schklowsky on 2012-02-21 16:00

As HTML5 grows its share of the online video market, web video publishers are beginning to look for ways to monetize videos being played outside of the traditional Flash advertising methods. But when someone watches a video in HTML5 mode, what should that experience be like? What's possible, given the current state of the tech?

HTML5: Desktop vs. Mobile

Before we begin talking about the challenges that face HTML5 video ads, it's valuable to acknowledge that video in HTML5 can behave very differently on the desktop compared to the same HTML code running on mobile devices. Here are some of the primary differences:

* Platform-specific

As you can see from the table above, some concepts that advertisers take for granted, such as video ads which cause a web page to be displayed when clicked, are not possible on smartphones. For example, on most mobile devices, once an HTML5 video begins playing, whether it's an ad or not, the phone will enter fullscreen video playback mode. In this mode, the user has full control over the playing video, including the ability to seek to the end of it.

Technical Challenges

As the major ad networks are beginning to offer support for HTML5 video ads, they face several important challenges.

Video Codec Incompatibility (WebM vs. MP4)

One issue which HTML5 video publishers are already familiar with is that to support all platforms, video must be encoded into multiple formats — WebM (or Ogg Theora) for Firefox, and H.264 for everything else. Second, someone (whether the browser, ad network, video player, or publisher) will need to select the appropriate format and display it to the user. This can be difficult to implement in an ad scenario, especially if ad networks don't account for the user's browser when generating an ad response.

Crossdomain Issues

An additional technical concern is that loading external assets (a VAST XML response from an ad server, for example) brings with it certain restrictions in JavaScript. These restrictions need to be worked around on the server hosting those assets.

<Video> Tag Access

Depending on the implementation, most ad networks require direct access to the player's <video> tag in order to play an ad in HTML5. This makes sense, considering that in iOS, each distinct <video> tag placed on a page needs to be clicked by the user in order for the video to be played. If the ad were to be played in a new <video> tag which was placed on top of the player, the user would need to click "play" twice - once for the ad and another time to watch the main video. This presents some interesting problems. While the ad is playing, the player needs to treat the events flowing from the <video> tag differently than if the main video were playing. After the ad has played, the video tag needs to be restored to its original state (the video playing, its position, etc).

Industry Roundup

Considering the relative newness of HTML5 video (and the challenges listed above), it's unsurprising that not many video ad networks have implemented full HTML5 support yet. That being said, there are a few ad networks who have made some progress on this front:

• Google recently released HTML5 support in their Interactive Media Ads (IMA) product. This implementation allows publishers to set up VAST ads, with certain limitations based on device compatibility. The JW Player's Google IMA Plugin includes beta support for HTML5 mode.
• YuMe has been steadily improving their HTML5 support, which is now supported in the JW Player's HTML5 mode via the YuMe plugin.
• Most other video ad networks (Tremor, SpotXchange, BrightRoll, and others) have either announced, or are currently implementing support for mobile devices, which will mean HTML5-compatible ad media.

Future Considerations

As in Flash, as more publishers attempt to handle more sophisticated scenarios, new techniques must be devised to handle them. Dynamic bitrate switching, for example, allows publishers make on-the-fly optimizations for video ads based on screen resolution and available bandwidth. Apple HLS (HTTP Live Streaming) is on its way to becoming the standard streaming format on mobile devices — with competition coming in the form of MPEG DASH, which was ratified as an ISO standard last week. Both HLS and DASH are based around the idea of a manifest file, which keeps track of smaller chunks of video that can be stitched together into a single seamless video. To insert an ad into this stream can be as simple as adding the ad chunks inside of the manifest file at the appropriate times, a technique known as dynamic ad insertion. A more general optmization we'll be moving towards is ad delivery which is optimized for variable-bandwidth environments, as many mobile users are viewing content over slower wireless networks.

In short, we're still a long way from having a turnkey video advertising solution for all HTML5 viewers, but we're closer than ever before to achieving that goal.

Comments (9)   Tweet   Share

JW Player 5.9: HTML5 Now Default on Android

by Pablo Schklowsky on 2012-02-02 12:59

As we continue to bring HTML5 support in the JW Player closer to parity with Flash mode, we've focused the 5.9 release on a variety of HTML5 stability and user experience updates:

HTML5 is now the default playback mode on Android Devices

In early November, Adobe announced it would stop developing its Flash Player for Android devices. As a result we've decided to focus our energies on optimizing HTML5 support on Android rather on a legacy platform.

Cleaner User Interface (Especially on iOS devices)

We've taken a number of steps to clean up the way the player looks and behaves, focusing on iOS. Although they're subtle, we think you'll appreciate them. Among the improvements are:

• The preview image now fades in when player loads
• Video is not displayed until it is sized correctly and ready to play
• The buffering icon appears on the iPad while video is loading

Saved Volume in HTML5

One feature from Flash mode that you told us you wanted to see in HTML5 was the player's ability to keep track of the last volume level selected by the user. Now, if a user reloads a page, or goes to a different page on your site, the player will be set up with the same volume (or mute state) as the last time they set it. (Note: this won't work on iOS, since websites are not allowed to set the volume of those devices)

Download the JW Player 5.9

You can download the JW Player 5.9 for Flash and HTML5 here. As always, we would love to hear your feedback on the release. Just post your comments directly to this blog.

Check out our release notes for this version. For a complete list of the tickets addressed in JW Player 5.9, please visit our developer site.

Comments (16)   Tweet   Share

JW Player 5.8 Released with Support for HTML5 Video Ads

by Pablo Schklowsky on 2011-10-18 09:00

This release of the JW Player 5.8 focuses heavily on stability HTML5 playback and secure plugin loading. The major addition is support for HTML5 video advertising for Google DFP and YuMe users. Read more to find out what's new.

Ads in HTML5 Mode

JW Player 5.8 introduces support for HTML5 video advertising. Users of the JW Player have become accustomed to providing a consistent user experience independent of the browser or device of their viewers, but until now the player didn't offer HTML5 video advertising support. With JW Player 5.8, we now enable HTML5 video ad support for both Google DFP and YuMe publishers - allowing users to run video and companion ads on iOS devices (iPhone/iPad). Check them out: Google Interactive Media Ads (IMA) & YuMe.

Increased Stability in HTML5 Mode

With the release of JW5.8, we took the opportunity to focus on video playback in HTML5 mode. Thanks to all the feedback you have given us, we've been able isolate the outstanding issues, and greatly improve the stability in HTML5 mode. We are always working to seamlessly integrate Flash and HTML5 modes, so please keep the feedback coming. For a detailed list of specific HTML5 improvements, see our developer site.

Secure Plugin Loading

If you manage a secure website, then you are probably familiar with the mixed content security warnings generated by browsers, particularly IE, when embedding the JW Player on a secure page. This was due to the fact that the JW Player always loaded its plugins over HTTP. JW Player 5.8 now detects if it is running on a secure page and loads its plugins over HTTP or HTTPS accordingly. Publishers embedding on Facebook should find this particularly helpful!

Download the JW Player 5.8

You can download the JW Player 5.8 for Flash and HTML5 here. As always, we would love to hear your feedback on the release. Just post your comments directly to this blog.

For a complete list of the tickets addressed in JW Player 5.8, please visit our developer site.

Comments (18)   Tweet   Share

HTML5 Video: Still not there yet, but making headway

by Pablo Schklowsky on 2011-10-10 10:00

Last year, we declared that HTML5 video was not quite there yet. Well, it's nearly 18 months since that post, so what's happened in the intervening time?

Let's start off with the positive: compared to 18 months ago, the browsers' implementations of the <video> tag have become much more stable. They also all have built-in support for pseudo-streaming (i.e. the ability to seek to an unbuffered position in the video file). The tools surrounding HTML5 video — streaming servers, transcoders, etc. — have also improved.

On the other hand, many of the issues we pointed to in our last post have not yet been resolved. HTML5 video is still "not quite there yet", but we'll take a look at the developments over the past year and make some predictions on where this is all headed.

Answering some open questions

In our last post on the subject, Jeroen mentioned three major issues which prevented HTML5 video from taking off. Let's see where these issues are today.

Codec support

The major question surrounding codecs revolves around whether open video codecs such as Google's WebM and Ogg Theora would overtake proprietary formats such as H.264. As before, this still comes down to browser and device support. Though the open-source browsers have decided on an open format — WebM — no current mass-market mobile device has hardware drivers which can decode VP8 (the video codec used in WebM).

On the desktop, the sides seem firmly entrenched. Apple has no interest in moving away from H.264, considering the investment they've made in the technology. Microsoft doesn't support WebM natively (users need to manually install the codecs). Firefox and Opera still have no desire (or, possibly, ability) to support H.264. And although Google announced in January that H.264 support would be removed from Chrome, more than 8 months later, there's been no indication when (or even if) this will happen.

The codec wars are still being fought full-steam. And the end result of the lack of a standard video format is that many publishers simply encode once — in H.264 — and rely on Flash for support in browsers that don't support it.

Streaming

We predicted that the browsers would choose to implement their own streaming mechanism to compete with Apple's HTTP Live Streaming (HLS) format (built into desktop and mobile Safari). The question would be what open standard would be chosen to build upon?

What happened instead is that this area was more or less overlooked. Safari Desktop and Mobile, and Android 3.0+ are still the only browsers with built-in support for an HTML5 streaming protocol. Publishers who require that their content be streamed (rather than simply downloaded) on any other device or browser must fall over to a Flash or Silverlight player.

Moreover, a common streaming format has still not been agreed upon. The browser vendors are reluctant to hitch their wagon to any one method of HTTP streaming — for technical reasons, and because they're waiting to see which formats users begin implementing themselves. Of course, this is something of a chicken-or-egg proposition.

Fullscreen

A draft standard for adding fullscreen support to browsers has been written up and more or less agreed upon. Safari has already implemented support for this in version 5.1. While no other browsers have implemented the necessary APIs, Chrome (which uses the same rendering engine as Safari, called Webkit) is probably the closest to making this a reality. Although Mozilla wrote the spec, there's currently no word on when Firefox will implement it Firefox has implemented fullscreen support in their nightly build, but the feature is disabled by default. In short, true fullscreen functionality is still lacking on most browsers.

It's worth mentioning that on most mobile phones (not tablets), HTML5 videos will always play in fullscreen mode. This is partially due to limitations in hardware, but it also makes sense from a usability perspective — if you're watching video on a web page on a 3.5-inch screen, do you really want to see anything other than the video itself?

What's coming up

So what can we expect within the next 6-12 months? We recently attended the Open Video Conference in New York, and rubbed shoulders with the people who are making HTML5 Video happen — browser engineers from Apple, Google, Mozilla and Opera were all in attendance (not to mention YouTube, Netflix, Internet Archive and many more). Everyone had a ton to bring to the table (Silvia Pfeiffer, who organized the conference's Open Media Developer track, has written a great summary of the work that went on). And while there's a lot of exciting technology being built, the core problems I mentioned earlier which are preventing HTML5 from becoming the de facto standard in web video (format compatibility and streaming) are still not being addressed in a unified way.

That being said, some of that new stuff is pretty cool, and may end up moving the needle. Let's take a look.

The <track> Element: Adding Text Elements to Media

The HTML5 <track> element is for adding timed textual metadata to a media element. This enables video players to add functionality to support subtitles, closed captions, chaptering and more. While none of the browsers currently support <track> natively, we got to see a cool JavaScript demo which added captioning functionality into a <video> tag.

Once this becomes a reality, text tracks will be an exciting new development in HTML5. It will help make video accessible to the seeing- and hearing-impaired, enable subtitles for foreign language speakers, and make video files indexable (and therefore searchable). All of these will pave the way for video and audio to become first-class citizens on the web.

MediaSource API: Direct access to video data

Google is working on a feature for Chrome, called the MediaSource API, which will allow JavaScript developers to manipulate video data at the lowest possible level (the byte stream). One application of this mechanism would be for video players to piece together small bits of video, serving as the basis for an adaptive streaming application.

This approach puts the onus on JavaScript video players, such as the JW Player, and on video content providers, to come up with their own solutions for streaming video in HTML5. While I'm sure there will be attempts at making this happen, the jury's still out on whether this method can become the basis for HTML5 video streaming, for the usual reasons — browser fragmentation, and the ever-present format wars (Chrome's implementation will only support WebM at first). My personal opinion is that until the browsers present a standard for HTTP streaming to developers and publishers, you'll see a couple of cool demos, maybe even an end-to-end solution (think Netflix or YouTube), but not an overall standard.

Conclusions

Yes, progress has been made. The tools are better (for example, the popular desktop encoder Miro Video Converter now includes support for WebM). The servers are better (Wowza Media Server and Adobe Flash Media Server (FMS) support both Apple HLS for HTML5 streaming and RTMP for Flash streaming). And the browsers are better, especially the mobile ones (many of the HTML5 video bugs in Android and iOS were fixed in versions 2.3 and 4.0, respectively).

So why did I say at the beginning of this article that HTML5 still isn't there yet? Why isn't Flash losing more ground, considering its own drawbacks (poor resource utilization, lack of support on iOS, to name a couple)? The simple answer is that Flash offers a safer, more uniform cross-platform environment for video developers and publishers, while HTML5 presents a dizzying array of browsers to test against, and competing formats to support. You still need both Flash and HTML5 to cover all of your bases, but most publishers are still choosing Flash as their primary video delivery platform for these reasons.

The JW Player will continue to stay close to the bleeding edge of HTML5 video, and we'll continue integrating both Flash and HTML5 together as seamlessly as possible. We're rooting for HTML5 and its promise of open standards, better accessibility and better performance. But it'll still be some time before HTML5 has everything it needs to take its place at the head of the table.

Comments (14)   Tweet   Share

JW Player 5.7: All about HTML5 Playlists

by Pablo Schklowsky on 2011-06-23 12:15

This release of the JW Player 5.7 focuses heavily on lifting HTML5 support closer to parity with Flash. The most glaring gap had been the lack of support for XML playlists and for a visual playlist UI component. We're happy to announce that those features are now available. Read more to find out what's new.

RSS Playlists in HTML5

The title says it all. You can now load RSS and mRSS (RSS with "media" extensions) directly into a player running in HTML5 mode. Please note, JavaScript applications must comply with browsers' Same-Origin policy, although there are a couple of workarounds.

Visual HTML5 Playlist Component

You can now scroll through your playlist with a visual component in HTML5 mode. This much-requested feature comes with full skinning support and works in desktop browsers as well as in iOS. Here it is in action:

This example even works on iOS!

Improved Plugin Control Over UI Elements

Calling all plugin developers: plugins can now keep track of when UI elements appear and disappear. This enables interactive plugins (e.g., sharing or advertising) can position themselves properly depending on whether or not the player's built-in controls are visible.

Stability and Performance Enhancements

This release contains 38 bug fixes and player enhancements, making the player more stable than ever before. See the release notes for more details.

Download the JW Player 5.7

You can download the JW Player 5.7 for Flash and HTML5 here. As always, we would love to hear your feedback on the release. Just post your comments directly to this blog.

Comments (32)   Tweet   Share

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 Flash Stage Video, and How Does It Affect Me?

by Pablo Schklowsky on 2011-02-22 14:50

Last week, Adobe released a new version of Flash - 10.2, containing a new hardware acceleration mode for H.264, called Stage Video.

Common Questions:

Doesn't Flash already support hardware acceleration for H.264?

In general, the answer to this question is "yes," if you're using Flash version 10.1. Your mileage may vary, depending on system hardware capabilities and Flash's support for various hardware. Here's how standard Flash hardware acceleration works:

• Video content is downloaded or streamed from content server.
• Flash passes the video bytes directly to the hardware H.264 decoder, if available.
• The decoder sends back the raw decoded video to Flash
• Flash composites the video with all of the other non-video visual elements (in the JW Player's case, this includes the controlbar, playlist, plugins, etc.). This happens for each frame of the video, assuming there are no skipped frames.
• The Flash plugin places the composited image into the web browser.

This method is vastly more efficient than the non-hardware-accelerated alternative, where Flash performs the H.264 decoding in software.

If Flash already has hardware acceleration, why do we need a new method?

In general, enabling hardware acceleration for H.264 decreases the load on the CPU. However, because Flash is still rendering video once per frame and compositing all of the Flash graphics with the video, there is still significant overhead involved. This manifests itself more clearly with larger videos (1080p and above) and slower CPUs.

Adobe's solution is to remove the video from Flash's rendering pipeline entirely. Enter Stage Video.

Here's how it works:

• Video content is downloaded or streamed from content server.
• Flash passes the video bytes directly to the hardware H.264 decoder.
• Flash instructs the decoder to render the video directly to the screen.
• Flash renders all of the non-video elements and places them on top of the rendered video.

Because Flash no longer has to make any calculations to render the video, this takes even more load off of the CPU.

Are there any limitations to Stage Video?

Yes, there are a couple of limitations, and for some applications, they can be a deal-breaker. Luckily, for most web video player applications, such as the JW Player, these limitations aren't as big of a deal:

• Since Flash is no longer involved in the video rendering pipeline, features such as visual effects, translations and transformations are not available in Stage Video mode.
• The "wmode" (window mode) Flash parameter must be set to "direct" in most browsers. This means that the Flash plugin can't be placed above or below any HTML entities on a web page. Stage Video is available in full-screen mode regardless of what "wmode" you use.

When will the JW Player support Stage Video?

We haven't nailed down a timeline for Stage Video support, but it's on the short list of future player improvements. We've already created a player with experimental support for Stage Video. You can download it here, and enable Stage Video acceleration by setting the provider option to stage. For now, only standard progressive download mode is supported (no HTTP or RTMP streaming).

To benchmark the new player, open up your Task Manager (on Windows) or Activity Monitor (on Mac OS X) and take a look at Flash's CPU utilization while watching an HD video. Try your video with provider set to stage, (Stage Video on), then switch provider to video to see how the player performs without Stage Video.

As always, we'd love to hear your feedback in the comments below.

Comments (11)   Tweet   Share

Introducing the JW Player for Flash and HTML5

by Pablo Schklowsky on 2010-10-12 00:00

For several years, the JW Player has been a leader in the web video world.  Until recently, this has almost entirely meant Flash video.  However, with the major browser vendors all committing to bringing video rendering capabilities directly into the browser, the landscape has begun to shift.  Additionally, the absence of Flash on certain critical platforms, such as the iOS devices, is pushing many web video publishers to search for alternatives.

Is HTML5 the Answer to All of Our Problems? 

It certainly addresses some major points:

• Standards Compliance - with the HTML5 <video> standard, publishers can simplify their video embedding, with the knowledge that their HTML will validate in all modern browsers.  Neither the <object> nor <embed> tags, which are used to embed Flash, have universally accepted standards.
• Open Web - Browsers are beginning to solidify support for open video standards, such as WebM and Ogg Theora.  Firefox, Chrome and Opera have all committed to delivering video content in royalty-free and open-source video formats.
• Device Variety - Devices with embedded video support, such as Apple and Android mobile devices, do not always have the capability to render Flash video.  The HTML5 <video> element allows the browsers on these devices to render video using cross-platform markup.

Why Not Move Everything Over to the <video> Tag? 

There are still some issues that get in the way.  First, as anyone who has played around with HTML5 video can attest, there's no single video format that is supported by all of the browsers, so videos must be encoded into multiple formats.  Second, with the <video> tag still in its infancy, browsers haven't yet standardized their implementations of the JavaScript APIs that support it.  Finally, a good percentage of desktop browsers (Internet Explorer 6, 7 and 8 make up 45% or more of the browser market) don't support HTML5 <video> at all, requiring some sort of fallback mechanism.

This is Where Flash Comes Back into Play 

Flash provides a uniform environment for web video, consistent across all desktop browsers (it has a 97% adoption rate) and even some mobile devices.  It offers a variety of advanced video delivery mechanisms, including bandwidth-saving streaming technology, live streaming, adaptive bitrate switching, and content security features.  And even if you have decided that you don’t need all that and will make the move to HTML5 <video>, you are still going to have to turn to Flash in order to provide a seamless experience for users not equipped with the latest browsers.

Several months ago, we began thinking of ways we could make things easier for publishers to get up and running with HTML5 video, so we released the JW Player for HTML5 Beta, which included a failover to Flash.  While this was useful for very simple configurations, we felt that it didn't go far enough in terms of end-to-end integration with the Flash version of the JW Player.  Ultimately, we realized that it wasn't two separate players we needed; instead, we should combine both of them into a single video player capable of rendering in both Flash and HTML5.  The result - the JW Player for Flash and HTML5.  Read the Official Press Release here.  Or, learn more about the enhancements and limitations of HTML5 Support in the JW Player. 

This Integration is Made Possible by Some Important New Features:

• Write-once embed code: A new JavaScript embedder allows you to write a single piece of embed code to embed in either Flash or HTML5 mode, depending on the configuration.  If the browser doesn’t support the configured mode, the player will automatically fail over.  Refer to the JW Embedder Section of our Supported Player Embed Methods Guide, for detailed instructions and live demos.
• Updated JavaScript API: Also included with this release is an updated JavaScript API, which enables you to easily write scripts to interact with the player, no matter which mode it’s currently running in.  Read More.

Last, this release introduces a number of improvements to the Flash playback mode, including automated RTMP/RTMPT failover.   Please take a look at the release notes for the details. You can read more about the JW Player for Flash and HTML5 here and Download it here.

We are always interested in hearing your feedback on ways to maintain the JW Player as the best video player on the web.  Post a comment below, or if you need help getting started, please visit our support forums.

Comments (7)   Tweet   Share

JW Player 5.3 Beta Integrates HTML5 Support

by Pablo Schklowsky on 2010-09-13 18:04

Given the overwhelmingly popular response to the HTML5 Beta, we have decided to incorporate the HTML5 player functionality into the 5.3 release of the player. This means you can create one block of embed code that will work across all devices that support HTML5 or Flash, including the iPhone and iPad! For browsers with both Flash and HTML5 support, the choice is yours -- simply configure the player's failover behavior.

UPDATE: The 5.3 release candidate (RC1) is now available.

UPDATE 2: The official 5.3 release is now available on our main Players page.

The really exciting part is that the unified Flash/HTML5 player will support a brand new JavaScript embedder and API, which will allow you to quickly write more interesting player customizations and interactions.

Here are a couple of examples of things you can do with the new API. Just download the zip file below, upload the contents into the folder on your web server as your test page, and you're good to go.

Embedding a skinned player with HTML5 failover

<script type="text/javascript" src="jwplayer.js"></script> <script type="text/javascript" src="jwplayer.html5.js"></script> <div id="container">This'll be the player</div> <script type="text/javascript"> jwplayer("container").setup( { file: "/videos/video.mp4", image: "/videos/video_thumbnail.jpg", skin: "/skins/skin.xml", width: 480, height: 270 } ); </script>

Setting event listeners

<script type="text/javascript" src="jwplayer.js"></script> <script type="text/javascript" src="jwplayer.html5.js"></script> <div id="container">This'll be the player</div> <textarea id="debug" style="width:480px;height:270px"></textarea> <script type="text/javascript"> // Setting event listeners is easy! jwplayer("container").setup( { file: "/videos/video.mp4", image: "/videos/video_thumbnail.jpg", width: 480, height: 270, events: { onReady: function(evt) { displayText("Ready"); }, onIdle: function(evt) { displayText("Stopped"); }, onBuffer: function(evt) { displayText("Buffering"); }, onPlay: function(evt) { displayText("Playing"); }, onPause: function(evt) { displayText("Paused"); }, onComplete: function(evt) { displayText("Finished"); }, onTime: function(evt) { displayText("Position updated: " + evt.position); } } } ); function displayText(message) { var debug = document.getElementById('debug'); debug.value += message + "\n"; debug.scrollTop = debug.scrollHeight; } </script>

Creating an HTML playlist

<script type="text/javascript"> jwplayer("container").setup({ file:"/videos/video1.mp4", width:480, height:270 }); </script> <ul> <li><a href="#" onclick="jwplayer().load('/videos/video1.mp4').play();">play first video</a></li> <li><a href="#" onclick="jwplayer().load('/videos/video2.mp4').play();">play second video</a></li> <li><a href="#" onclick="jwplayer().load('/videos/video3.mp4').play();">play third video</a></li> </ul>

We're about to send the player into QA for a complete round of testing, but before we do, we'd love to hear your feedback on the new API and embedding mechanism. What do you like? What do you hate? Can we make this better? Now's the time for your voice to be heard.

The beta can be downloaded via the link below. Remember, this is definitely a beta product and you'll likely encounter a bug or two, so don't go updating your production player just yet. That being said, we'd love for you to grab it, play around with the new API, and let us know what you think!

Comments (86)   Tweet   Share

JW Player 4.7 Released

by Pablo Schklowsky on 2010-07-14 17:51

We've released two player updates this week which bring bug fixes to the v4 and v5 players. JW Player version 4.7 is purely focused on bugs, and marks the end of life for the v4 product line. The 4.7 release fixes a number of bugs collected in the months since the release of 4.6, addressing streaming server support, bitrate switching and general stability. Noncommercial users can download the player here, and license holders can get the commercial version here. 

You can find all of the complete v4 documentation here.

The patch to 5.2 (5.2.1151, for those of you keeping score at home) addresses a problem with loading external Media Providers, as well as an issue pertaining to the Flash Player 10.1 update (release notes). The new version is available on our Player Download Page.

Comments (2)   Tweet   Share

Amazon CloudFront Brings Streaming to the Masses

by Pablo Schklowsky on 2010-07-07 17:35

When Amazon introduced RTMP streaming for CloudFront, it was big news for the Flash platform in general, and here at LongTail it has been no exception. Overnight, RTMP became a hot topic on our forums, where before we had only heard from veterans in the Flash video space. It's not hard to understand why, since RTMP has been expensive and difficult to configure for most folks. In addition to RTMP streaming in general, we're fielding a lot of questions on CloudFront's support of RTMP. What does it support? How do I set it up? Is it right for my site? This post will attempt to answer these questions, as well as provide some background on video streaming on the Flash platform.

Streaming Video With Flash

For most people, RTMP is just another serving of web-jargon alphabet soup. Let's clarify it a bit. RTMP (Real Time Messaging Protocol) is a web transmission standard which allows a backend server to transfer video, audio and data to the Flash Player. It's particularly useful for video streaming, since the Flash Player can communicate back to the server about how much video it has consumed, and how much more video the server needs to send. This is a distinct advantage over so-called progressive download video, where a web server simply begins sending bytes out to the video player over standard HTTP until there are no more bytes to send.

When Amazon CloudFront was first introduced, it only supported progressive downloads as a mechanism for serving video content. While this was very simple to set up (no different from serving other static files, such as images and text, from a CDN), it came with all of the usual disadvantages of progressive download video delivery:

• Wasted bandwidth - While most viewers will only watch a small portion of the video, many will download the entirety of the video. This means higher bandwidth costs for the publisher, and less available bandwidth for other viewers.
• Limited seeking - With progressive downloads, the viewer can only seek to areas of the video that have already been downloaded.
• No long videos - For long-form or high-bandwidth videos, progressive downloading is not recommended as it can slow down (oer even crash) a viewer's browser.

Now, with CloudFront's support for RTMP, you can stream your video content. RTMP Streaming addresses the above issues, as well as providing some additional benefits. In addition to saving bandwidth and allowing better seeking control, RTMP can do some neat tricks:

• Harder to steal - RTMP traffic is more difficult (although not impossible) to hijack than video transmitted over HTTP.  Additionally, RTMP servers have several mechanisms to encrypt and sign streamed content.
• Dynamic Bitrate Switching - Newer RTMP servers have the ability to switch seamlessly between two videos, provided the Flash player connected to the stream is using Flash version 10.0 and up. This means that if the viewer's bandwidth drops below the bitrate of the stream, the player can switch to a lower resolution without interrupting the viewer's watching experience.
• Live Streams - RTMP has the ability to stream live content as it comes in.

RTMP in the CDN Market

Several CDNs, such as Akamai, EdgeCast, Limelight and Highwinds support RTMP streaming. CloudFront started offering pretty much the same functionality. So why should you care?

The first answer is in CloudFront's pricing model. For small publishers (the vast majority) it offers RTMP streaming at a fraction of the cost of other CDNs. Also, while most CDNs don't publish their price structures (the only way to find out how much they cost is to contact each one directly and get a quote), Amazon's pricing is posted clearly and is quite competitive. Their a-la-carte pricing starts at $0.15 per GB if you stream under 10 TB per month (for US and EU edge nodes; the price goes up for Asian traffic).

Another benefit to using CloudFront Streaming is that it's very easy to set up with the JW Player. All you need to begin streaming from CloudFront is an Amazon Web Services account, a credit card, and some video content to upload.

We've heard some people tell us they're concerned about the ability to scale with AWS, since their published pricing does begin to lag behind the other CDNs at the high end. This could be the case, but there are many examples of enterprise companies (such as Sorenson Media) who use CloudFront.

One feature of RTMP which most CDNs support, but that CloudFront does not, is live streaming. As of today, Amazon's website says that they intend to support live streams on CloudFront in the future. For some people this is obviously a deal-breaker, but if you're not casting live streams, this won't effect you in the slightest.

Conclusions

CloudFront's support of RTMP is a big step forward in the online video industry. It allows publishers to implement an advanced streaming technology using a self-served, pay-as-you-go pricing model. This low threshold is why Bits on the Run, LongTail's online video platform, has a new beta feature adding support for CloudFront. When you sign up for Bits on the Run, you have the option of linking your Bits account to your CloudFront account, and Bits takes care of the rest. This makes setting up RTMP streaming extremely easy, including such features like dynamic streaming, log aggregation, private content and DNS masking.

Is CloudFront a game-changer in the CDN industry, as many have predicted? I'm not sure I'd go that far, but given Amazon's self-service design, relative ease of use, aggressive pricing structure and integration with their other web service offerings (S3 and EC2, to name a few), CloudFront is a compelling option, especially for the thousands of smaller video publishers.

Interested? Then check out this tutorial to start streaming.

Comments (5)   Tweet   Share

JW Player 5.2 Introduces New Skinning Features

by Pablo Schklowsky on 2010-06-04 17:19

We're pleased to announce the release of the JW Player for Flash Version 5.2.  One of the JW Player's strongest features is its flexible skinning model.  Our focus for JW5.2 has been on improving on its XML/PNG skinning abilities.

We've also fixed over 30 discrete bugs, and added a number of performance and feature enhancements.

New Skinning Features

• The Controlbar, Your Way - Previously, skin designers could only alter the look and feel of the controlbar buttons. With JW Player 5.2, you can now lay your controlbar buttons out in any order you want, as well as insert any non-button image into the controlbar's layout. Also, there are no longer any required controlbar elements, so you can leave out anything you don't want.
• Customized Buffer Icons - With JW Player 5.2, you have more control over the rotation of the player's buffering indicator. You can control how fast the icon rotates, and the angle of each rotation.
• Fine-Grained Color Support - The new skinning model now supports customized background colors for every player component. You can have one background for the playlist, another for the controlbar, and a third for the display. You can also set colors for all of the text fields in the player as well.
• Advanced Font Controls - The skinning model now supports customization of the controlbar and playlist's text fields. You can change the font size, color, and use all Flash-supported system fonts (_sans, _serif and _typewriter). You can even make them bold and / or italic. Go nuts!
• Slider End-Caps For Everyone - A much-requested feature was the ability to add end-caps to the controlbar and playlist slider elements. The 5.2 player now allows you to create end-caps for the volume slider, the time slider and the playlist slider.

Say Hello to Glow

Created by JW himself, the new Glow skin takes advantage of the new 5.2 skinning features. Check it out for yourself:

You can download the Glow Skin from our Skins Library.

Other Updates

Not a skin designer? No problem! Just sit back and wait as some sweet new skin submissions begin appearing in our Skins Library. We've also got a few updates for you:

Enhancements

• Improves switching logic for dynamic RTMP streams
• Handles YouTube's upcoming URL change
• Specifies playlist and plugin sizes in percentage rather than pixels
  • Example: "playlist.size=50pct"
• Adds support for a "playlist.image" playlist item property, which allows a different thumbnail image to be displayed in the playlist

Bug Fixes

JW Player for Flash Version 5.2 fixes over 30 bugs. Here are a few of the major ones:

• Allows YouTube videos to be embedded in HTTPS pages
• Makes the YouTube logo clickable
• Fixes an issue where some dynamic streams only switch on resize events
• Fixes an issue which would cause dynamically switched RTMP livestreams to close early
• No longer hides the the display image when playing AAC or M4A audio files
• Allows querystring parameters for .flv files streamed over RTMP. This fixes a problem some Amazon CloudFront users were having with private content.

To see everything we've done in this release, check out the complete list of changes in JW Player 5.2 on our developer wiki.

  Tweet   Share