Entries By zachary ozer
Using a Web Proxy to Test and Debug the JW Player or: Why Charles is our Best Friend
by Zachary Ozer on May 12, 2011
One of the tools that we've come to rely on quite heavily over the past several years is a web proxy. Frequently, we see support requests come in where a publisher has misconfigured the player by pointing it at a video file or skin which does not exist on their server. Using a web proxy, it's possible to log all requests, making it quite easy to see when requests are failing because the file they're trying to load isn't there. Additionally, since some web proxies allow you to modify requests, publishers can test out new player versions, plugins, or skins without modifying any code on their live site. In this blog post, we'll show you how to use a web proxy called Charles to help you debug your current JW Player configuration and test out new configurations.
How a Web Proxy Works
When you're running a web proxy, it acts as a middleman between your web browser and the website you're trying to access. Normally, your web browser makes requests directly to a website. When a web proxy is running, it acts an intermediary for all of your traffic, receiving all requests and then dispatching to the website as needed. This means that it's able to log requests, modify them, or allow them to pass through normally - and all of this occurs transparently to your web browser.
Setting up a Web Proxy
Getting and setting up a basic web proxy is easy! Browsers like Chrome, Safari, and Opera have developer tools with a basic proxy built in. For Firefox, there's the popular Firebug extension. These allow you to monitor outbound requests and see what your server is returning for each request.
Around the office though, we use Charles Proxy. Rather than simply logging requests, it allows you to modify them as well - pointing one network location to another, or pointing network files to files on disk. Additionally, because Charles exposes its proxy to the general network, it's possible to use a desktop running Charles as a web proxy for devices like the iPhone, iPad, and Android handsets.
A Few Examples
There are a few common cases where a web proxy is exceptionally useful. These examples only scratch the surface of the power of a web proxy, but they should get you well on your way.
Inspecting Your Web Browser Traffic
The most widely used feature of a web proxy is it's ability to monitor web traffic and it's the basis for all of the other examples that we'll talk about in this post. Once you've successfully installed Charles, go ahead and launch the application. You'll see a screen that looks like this:
Once the application has finished loading, open up your web browser and navigate to a page where you'd like to monitor the web traffic, like so:
As your web page loads, you'll see the request log growing in Charles. Clicking on any individual entry will give you detailed information on the file loading including HTTP response code, size, and time to load:
Validating Your File Paths
The example below shows a standard player configuration using a player with a video, thumbnail, and skin. After opening the web page containing this player in our web browser, we found that the thumbnail image wasn't appearing. Next, we launched Charles, cleared our web browser's cache, and reloaded the page in our web browser. It turns out that the file location we used for the thumbnail doesn't exist! To indicate that the file is missing, Charles placed a red circle with a question mark next to the filename and listed "404 Not Found" in the response code field, as demonstrated in the highlighted entry below:
You'll want to be sure to check the entire request log for 404s - it's pretty common for things like crossdomain policy files to be missing as well.
Confirming that the GAPro Plugins is Tracking Correctly
When you first start using the GAPro plugin, the process of testing your configuration and waiting for new data to appear is quite time consuming, as it may take up to 24 hours for Google to process the new event data. Rather than wait, simply boot up Charles, navigate your web browser to a page containing a JW Player configured to use the GA Pro plugin, and look for a call to Google Analytics in Charles, like so:
Testing Your Site with a New Player Version
We always recommend testing out our new player versions with your site's configuration before upgrading. Charles provides a powerful tool, called Map Remote which will help you accomplish this without any special testing pages for your site. First, upload the new player.swf and player.js files to your site, but don't overwrite your existing player. Next, open Charles and point your web browser to a page that currently contains a JW Player, and that you'd like to test with your new JW Player. Look through the requests in Charles to find your player in the list of requests and right click it. You'll see a menu like this:
Select "Map Remote". A dialog box will open. The original address will automatically be populated in the top section, labeled "Map From". Now, enter the address for the player you're trying to test in the box labeled "Map To", like so:
Finally, if you clear your web browser cache and reload the page in your web browser, you'll only see a request to the new file, with a note indicating "Mapped from remote URL: ".
Assuming your configuration worked, you can go ahead and replace your original player.swf and jwplayer.js with the new player or update your site configuration to use the new player. Be sure to close Charles when you're done testing, otherwise you might continue to map to a file that doesn't exist!
Note - In addition to testing out a new player, you might also want to test out an entirely new player configuration. Rather than using "Map Remote" as you would when testing a new player, you'll want to use "Map Local", which allows you to point to a file on your file system. Thus, to test out a new configuration, simply download a copy of the page you'd like to test onto your desktop, make the changes to your embed code locally, and then point the remote address with that file to the version on your desktop. Everything will remain the same on your live site, but you'll be able to test your new configuration locally with all of the images, scripts, and advertising loading as they would for your viewers.
Configuring iOS to Use Charles
You can also configure your iPhone and iPad to use Charles for testing. First and foremost, it's important to make sure that your iOS device and your computer are using the same network (wifi or wired) - none of this will work otherwise. Once you've verified this, go ahead and fire up Charles. After Charles has finished starting up, you'll need to figure out your computer's network IP address (instructions are readily available for Windows and Mac). In this example, the IP address of the computer is 192.168.0.116. Next, open up the network configuration on your iOS device and set the HTTP Proxy to your IP address on port 8888, as demonstrated in the highlighted box below:
The next time you open up Safari on your device and navigate to a page, Charles will prompt you with the following message:
Simply click "Allow", and all of your iOS device requests will be logged and routed through Charles just like your normal browser requests.
Limitations of Web Proxies
Web proxies work great for many player configurations, but they have certain limitations as well. For example, Adobe's RTMP streaming protocol uses a lower level network connection, thus bypassing most proxies. If you're using RTMP, you can still use a proxy to confirm that your thumbnails, plugins, and skins are properly configured, but there's no way to ensure you've pointed to the correct video assets.
Hopefully you've now got a good grasp on what a web proxy is conceptually and how it can help you setup, configure, and troubleshoot your JW Player. As you use web proxies more, you'll continue to find new and amazing possibilities. Please be sure to share your discoveries in the comments!
Publish Your Videos to Facebook with a JW Player
by Zachary Ozer on April 13, 2011
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.
JW Player 5.5 for Flash and HTML5 Introduces JavaScript Plugins
by Zachary Ozer on March 14, 2011
When we released the integrated JW Player for Flash and HTML5 in October, we also released an updated JavaScript API and our own Embedder. Both were designed to make it as simple as possible to get your content and code running for all viewers, regardless of their device.
Today, we're making it even easier with JavaScript plugins, an HTML5 dock, and alternative embed configurations.
JavaScript Plugins
Since their introduction in JW Player 4, plugins have always been a popular feature of the JW Player. Over the past several years, our developers have worked hard to create dozens of plugins, adding indispensable functionality and fun features. Additionally, our hosted plugins repository has made it super easy for publishers to start using these plugins.
With the launch of the integrated JW Player for Flash and HTML5, it was possible to write scripts that interacted with the player in both Flash and HTML5 modes, but there was no convenient way to distribute that code - until now. With JW Player 5.5, the player will handle the loading of JavaScript plugins in both Flash and HTML5 modes. Just like with Flash plugins, it's as easy as adding another line to your embed configuration, like so:
<div id="player"></div>
<script type="text/javascript">
jwplayer('player').setup({
flashplayer: 'player.swf',
levels: [
{file: 'bunny.mp4'},
{file: 'bunny.ogv'}
],
height: 270,
image: 'bunny.jpg',
plugins: {
'helloworld': {
text: 'Hello world!'
}
},
width: 480
});
</script>
This loads the Hello World JavaScript plugin from LongTail's plugin repository and registers it with the player:
(function(jwplayer){
var template = function(player, config, div) {
function setup(evt) {
div.style.color = 'red';
div.innerHTML = config.text;
};
player.onReady(setup);
this.resize = function(width, height) {};
};
jwplayer().registerPlugin('helloworld', template);
})(jwplayer);
No need to download plugins and no need to distinguish between Flash and JavaScript plugins. The player takes care of it all.
If you're interested in building JavaScript plugins, be sure to join our developer list and check out our guide to Building JavaScript Plugins.
Alternative Embed Configurations
Since it's original release six months ago, the JW Embedder has matured tremendously. The original release simply allowed publishers to control whether to use Flash or HTML5 as the primary embed method. In JW Player 5.4, it gained a download mode and greatly refined the logic around when to embed.
Now, the JW Embedder allows you to specify different configuration for each embed mode. This is especially meaningful for publishers who want to take advantage of numerous benefits of a streaming server like Adobe's Flash Media Server or Wowza's Media Server while still allowing mobile users on iOS or Android to view their content.
While we still officially recommend using SWFObject for embedding, the JW Embedder will soon be our offically recommended way of embedding the JW Player. This will help ensure that all sites using the player will have HTML5 support for both player and plugins.
There are several other enhancements and small bug fixes which are listed on our developer site.
Download the JW Player 5.5
You can download the JW Player 5.5 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.
Sneak Peek: The JW Player JavaScript Plugin API
by Zachary Ozer on January 03, 2011
With the release of JW Player 5.3, we introduced a new JavaScript API. One of the biggest limitations of the JavaScript API is that it didn't provide a way to easily package and distribute code.
Today, we're happy to offer a preview of our new JavaScript Plugin API to developers. This builds on the JavaScript API released in 5.3, but allows developers to distribute their plugins through the LongTail plugin repository, making it incredibly simple for publishers to start using their plugins.
In addition to loading the plugins, the player does a lot of the heavy lifting for developers: providing a reference to the player API for controlling the player and adding listeners, parsing the plugin's configuration, and it even creates a DOM element where plugins can place visual assets.
To get started, go ahead and download the preview SDK below. Inside, you'll find a modified version of jwplayer.js, an example plugin, a test page that demos the example plugin, the developer documentation, and a document outlining our thought process as we developed plugin API. Note: You'll need to run the test page from a web server (local or global) in order to get everything to play nicely with Flash security.
We've thought a lot about the plugin API, but we want to get your feedback before officially releasing it. If there's something that doesn't seem to be working correctly, something we haven't included, or if there's something that's wrong with our design, please let us know by leaving a note in the comments below. We'll be making changes and posting updates as the feedback comes in.
Happy building!
Download the JW Player JavaScript Plugin API preview SDK zip
UPDATE: The 5.5 release candidate (RC1) is now available.
JW Player 5.4 for Flash and HTML5 Released
by Zachary Ozer on December 13, 2010
We are pleased to announce the official release of JW Player 5.4. Version 5.4 supports both Flash and HTML5, and is an improved version of the recent JW Player 5.3 for Flash and HTML5 release. The 5.3 release was a big step forward for the JW Player, introducing a built in embed mechanism, HTML5 support, and a new JavaScript API. Our overarching goal with 5.3 was to make it easier for publishers to distribute their content to all devices and for developers to build amazing products that work seamlessly across all platforms.
What's New in 5.4?
With the 5.4 Release, we've been working hard to improve player performance, stability, and most importantly, making content accessible on even more devices. To achieve our goal of maximum compatibility, in 5.4, we've added a download mode for the player. In practice, this works by detecting if a viewer has either Flash or HTML5 playback capabilities on their device/browser, and then providing a download link if neither is available. This means that viewers using devices like the BlackBerry, Symbian handsets, or older Android builds will still be able to view the content.
We've also enhanced the embedder's ability to detect which mode of the player provides the best experience for viewers. Publishers still have the ability to specify which mode of the player they prefer their viewers to use, but in the event that the default mode is unable to play back the video, we'll check the other listed modes to see if they're able to playback the video. For example, if you've set HTML5 mode as your default and you're trying to play MP4 or WebM in Firefox, the player will now fail over to Flash and play the MP4.
There are several other enhancements and small bug fixes which are listed on our developer site.
The highlights include:
- Support for Apple .M3U8 playlists for HTML5
- Stretching mode configuration is honored in HTML5 mode
- The JW Embedder and HTML5 mode are now compatabile with the most popular JavaScript libraries, including MooTools and Prototype
- The JW Embedder now allows wmode configuration for Flash mode
- Seek calls are now queued if the player is not playing when they are made
Download the JW Player 5.4
You can download the JW Player 5.4 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.
FOMS: Funny Name, Serious Talk about HTML5, Bitrate Switching, WebM, and WebSRT
by Zachary Ozer on October 08, 2010
Last week, in the midst of our normal support requests and software development, we found a way to squeeze in a little extra time to attend the Open Video Conference and associated meetings here in New York. Everyone here at LongTail is a strong believer in open media formats, but it is rare to see so many people who are as committed to it as we are - assembled in one place.
For most of us, the most exciting part of this whole week was the Foundations of Open Media Software Workshop, organized by Silvia Pheiffer, a member of Xiph.org and frequent contributor to the HTML5 media specification.
Bitrate Switching
Going into the workshop, we were especially interested in hearing everyone’s thoughts on adaptive bitrate switching. While this is one of the most popular features of our Flash player, HTML5 doesn’t offer any mechanism for handling this, so we can’t offer this functionality in our HTML5 player. Thankfully, the workshop included a brilliant mix of browser vendors (Philip Jägenstedt from Opera, Chris Blizzard from Mozilla), Codec designers (John Luther of WebM and Christopher “Monty” Montgomery, Gregory Maxwell,Timothy Terriberry, and Ralph Giles of Ogg Theora and Vorbis), and player developers (Steve Heffernan of VideoJS, Michael Dale of Kaltura).
Several viable alternatives were presented for bitrate switching, however, there are several technical challenges to contend with. First, there is a question as to whether to use several long files and simply switch between them using range requests, or to break the files up into thousands of short (~5 second) "chunks", and play them back sequentially. Ultimately, using several long files presents a big challenge, both in terms of time to start playback and live streaming. All current file formats would require that the index of switch points be loaded for all files before starting the video. This dramatically increases the amount of time required to begin playing back a video and makes live streaming impossible, since the index could not be dynamic. Additionally, while a new file format could be designed to handle this, it would be difficult to achieve widespread adoption.
This meant that a mechanism that used several manifest files and many small files seemed quite attractive. The browsers would simply load the manifest for the appropriate quality, and then load a different manifest if necessary. Furthermore, the browser could periodically check for additional entries in the manifest, effectively allowing for a livestream with DVR. The browser vendors noted that this could be very simple: they will need to implement a mechanism for synchronizing media playback over multiple files for accessibility (alternate audio tracks) regardless, so why not use this to simply stitch together video files, one after another? Finally, this mechanism closely mimics Apple's bitrate switching mechanism, so it has a proven track record, and the tools built to support it.
Unfortunately, the format discussion was so involved, it left little time to discuss how the browsers would choose to switch streams. A loose JS API was proposed for this, with the possibility that browsers would build in their own default logic. However, based on this feedback from the group, we will draft a specification for this, post it for feedback, and include it in the JW Player as soon as possible.
WebM
One of the other highlights was the community’s interest in WebM. Much of the video on the web today relies on the H.264 for encoding video. Unfortunately, H.264 cannot always be used without paying royalties to a licensing organization, MPEG LA. While the HTML5 video spec was being developed, Ogg Theora was the only realistic open source alternative to H.264. Unfortunately, it’s performance is not nearly as good as H.264. WebM is a project that was started up by Google after their acquisition of ON2, which offers a high-performance, royalty-free codec for video. For this reason, the participants were especially interested in the possibility of adopting it as the baseline codec for HTML5. In fact, our HTML5 player already supports it, as both Opera and Chrome have this functionality built into their production browser, and Firefox has it available in their new beta. The biggest concern was that Apple and Microsoft have both refused to include support, and while Adobe recently announced VP8 support, there have been no dates set.
WebSRT
Finally, there was a discussion over web accessibility, specifically subtitles and closed-captions. This is near and dear to our heart, as JW recognized the importance of this early on, and made sure to include accessibility functionality ever since. The new standard for subtitling and captioning on the web will likely be WebSRT, and we’ll be working closely with the drafters of that specification and browser vendors to include support as soon as possible.
As intellectually stimulating (and fun) as these workshops are, it’s important to us that we’re a part of these discussions so that we can continue to develop the most innovative products, and that those products are standards based. So keep your eyes peeled – we’ll be working hard to integrate these technologies into all of our products as the standards develop.
Securing Your Content
by Zachary Ozer on August 09, 2010
Since the Napster trials in late 1999, content producers have become increasingly aware of intellectual property issues. Even then, the Recording Industry Association of America (RIAA) tried to send the message that the Internet had made widespread piracy possible, and that it was leading to enormous losses in revenue for the music labels and artists.
In addition to direct losses from piracy, content producers today face an even greater challenge when it comes to controlling how their work is distributed. It's quite common for anyone who admires your video to simply repost it on their site. Generally, this isn't a big deal - it's flattering and it provides a mechanism for increasing the visibility of your work. Unfortunately, this redistribution can also lead to a poor perception of your work and it can also dramatically increase your web-hosting costs.
With that in mind, I'd like to introduce "The Golden Rule":
Anyone who can watch your video can steal your video.
It is very easy to become paranoid about protecting your content. We'll try to offer a few simple steps that you can take to defend against most unauthorized uses, however you will need to take into account the technology you have available, the time amount of time you can invest in setting everything up, and the amount of money you're willing to spend.
Security for Individuals
The most basic form of protection is obfuscation, which can be accomplished on the web with JavaScript. In order to watch your video, a viewer's computer must first know its location. As a result, the location is generally printed right in the source code of the page with the video. Using JavaScript, it's possible to do some complicated text replacements so that the actual address isn't immediately visible. As easy and useful as this seems, most web browsers offer an interface for inspecting web traffic, which will always display the non-obfuscated address, thus rendering this solution ineffective.
This is a prime example of client-side security, which means that the actual security measure is written into the software running on the user's computer. However, given the limitations of this type of security, most content protection relies on a completely different type of security: server-side security. Server-side security is much more reliable as regulates access at the source and only relies on hardware you control.
The most widely used form of server-side security is web authentication. If your web browser has ever popped up a dialog box and asked you for a username and password, then you've used web authentication. The best part is that most web common servers have this functionality built in, which makes it incredibly cheap and easy to implement. In fact, configuring web authentication can be as simple as creating a text file. But be careful - it's very easy to give users access to content they shouldn't be able to see and it can become time consuming to manage. In fact, web authentication is relatively insecure in practice as individuals often share their usernames and passwords. For this reason, it's not recommended in an organizational setting, but it's perfectly appropriate for sharing between a few trusted individuals.
Security for Small and Medium Sized Organizations
Just like web authentication is the de-facto security mechanism for individuals running their own web servers, temporary URLs are the de-facto security mechanism for organizations using a content delivery network (CDN). Sites using temporary URLs generate a new link to a video file every time a user loads the page. This link is only valid for a short period of time or a limited number of accesses. Once it has expired, individuals who want to view the content will have to request a new link. This makes it incredibly effective at protecting against leechers (people who copy-and-paste your embed code into their site), since the link that's copied will eventually expire. In fact, many video hosting services, such as Bits on the Run and Amazon Web Services' CloudFront readily promote this.
Temporary URLs become even more effective when uses in combination with encrypted streams. This prevents malicious individuals from intercepting web traffic on your network in order to reconstruct the video, since only the viewer at the end will have the credentials to decrypt the video. The most commonly used implementation is Adobe's Flash Media Server (FMS) with encrypted RTMP. While individuals have created software that allows viewers to extract the video from these streams, they are not widely used, in large part due to legal action by Adobe. Both Bits on the Run and Cloudfront offer encrypted RTMP streaming via FMS, and it works in combination with their temporary URL mechanisms.
Security for Large Organizations and Institutions
No discussion of content security would be complete without mentioning digital rights management, or DRM. While DRM is the most secure form of content protection, it's really only suitable for large organizations, owing to its cost and complexity. DRM solutions use special cryptographic algorithms when encoding to ensure that only individuals with the proper credentials are able to decrypt and view the content, and often only after being authenticated by a DRM server or for a specified period of time. Not surprisingly, vendors charge a pretty penny for the software ($40,000+ in licensing fees are not uncommon), and this says nothing about the cost of maintaining and running the necessary server hardware.
Additionally, DRM blocks many legitimate users, especially those using mobile devices. For example, Apple's DRM solution for audio, video, and eBooks, FairPlay, only works on Apple devices or computers running QuickTime. Microsoft's PlayReady DRM has been supported by their cross-platform Silverlight player since version 2, but only after they abandoned their PlaysForSure DRM solution, stranding many users with unplayable content. Finally, Adobe's Flash Access DRM has only recently become available to clients with the release of Flash 10.1, so it's ability to deliver secure content to clients is still limited.
Conclusion
Hopefully you are now aware of the need to protect your content, and feel equipped to make a decision about what type of protection best suits your needs. Clearly, the challenges associated with securing original content online have continued to increase as people have sought out ways to circumvent protective measures. And so while technical solutions to protect intellectual property continue to grow more complex, you should always remember one thing: that your videos are your property and you have a right to protect them.
Introducing the JW Player for HTML5
by Zachary Ozer on May 12, 2010
Today, we're pleased to announce the beta release of the JW Player for HTML5. The JW Player for HTML5 leverages new technology within modern web browsers to playback video without the need for plugins or addons. This has the potential to improve both user experience and performance, especially as browsers begin to take advantage of the hardware-based video decoding available on most devices.
That having been said, no browser on the market today has the extensive playback capability of the JW Player for Flash. For that reason, we've built in a seamless fallback for those viewers who can't take advantage of these improvements.
Although we've labeled the player as beta, you'll still find a fully functional player jam-packed with features, including:
- Full support for all browsers, including Internet Explorer, Firefox, Chrome, Safari, Opera, iPad, and iPhone
- Playback capabilities for H.264, Theora, and FLV
- Support for all JW Player PNG Skins and
- An extensive API for those who want to add in additional functionality
You can download the JW Player for HTML5 here.
The JW Player for HTML5 is the newest in our long line of players and demonstrates our continued commitment to supporting the most innovative technologies. Should you have any issues, please don't hesitate to contact us via our support forum.