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.
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.
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.
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.
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:
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.
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:
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.
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.
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!
by Ethan Feldman on December 03, 2010
Prior to the JW 5.3 release, the most common methods used to embed the JW Player on your website were object/embed code and swfobejct (1.5 or 2.X). With the release of JW 5.3, we also introduced our own embed method, the JW Embedder, referenced as jwplayer.js. We recommend the JW Embedder when you’re looking to achieve the following:
This blog post is going to cover how to use the JW Embedder. Note that if you are familiar with the swfobject 2.X embed method, you will notice some similarities.
Let's get started...
Here is a basic player setup using jwplayer.js:
<script type="text/javascript" src="jwplayer.js"></script>
<div id="thePlayer"></div>
<script type="text/javascript">
jwplayer("thePlayer").setup({
flashplayer: "player.swf",
file: "file.mp4",
height: "270",
width: "380"
});
</script>
Now Let's break this down, line by line:
<script type="text/javascript" src="jwplayer.js"</script>
This line should point to the location of jwplayer.js on your server. If you do not include this line, or you are pointing to the jwplayer.js file incorrectly, the JW Embed method will not work.
<div id=" thePlayer"></div>
Next, you have a div tag, with an id of thePlayer. This is a basic html tag, with an ID where you specify the ID in your actual embed of the player itself. This div will be completely replaced by the player.
<script type="text/javascript">
Next line represents the actual player embed itself, enclosed in a script tag.
});
Closes the setup variables you’ve defined.
</script>
Finally, the entire embed is closed out with an ending tag.
I hope this blog post helped explain how to embed the 5.3 player using the new jwplayer.js embedding mechanism. Happy embedding!
by Ethan Feldman on October 28, 2010
Common misunderstandings about HTML5, Flash, and the JW Player
The release of JW Player 5.3 introduced some important new changes to our player, and its embedding mechanisms. Both the JW Player for Flash and the JW Player for HTML5 are now completely incorporated into JW Player 5.3. As always, we've received great feedback from our community which has helped us compile this list of common misunderstandings about the Flash Player, the HTML5 Player, and Flash/HTML5 in general. With this post, I hope to help you get started with the JW Player 5.3 for Flash and HTML5.
Ready? Let’s Get Started!
1) The 5.3 player.swf file does not contain the HTML5 Player
I know this might sound obvious to some of you, but the 5.3 version of player.swf does not contain the HTML5 player. For those who are less familiar, the .swf file format is a Flash-specific format. The entire HTML5 player exists within a file called jwplayer.js (our new JW Embedder), which comes in the new .zip file for the 5.3 player. Inside of this .zip file there is also a PDF with details on the new JW Embedder, how it works with the player, and a specific section dedicated to the player's HTML5 support.
2) I uploaded the new player.swf file to my site, but the HTML5 player does not work on my iDevice
This misunderstanding is related to the first point we just addressed. Note that in order to use the HTML5 player, you need to embed the player using jwplayer.js. Why? Because all of the HTML5 player code exists within this file. In cases where you set the HTML5 player to be the default mode, the player.swf file is only there for Flash fallback purposes. The idea behind this orientation is to present a seamless experience for the end user. The end user should always see a working video player, regardless of what browser/device they are viewing the video with.
3) I am embedding the HTML5 player, but it doesn’t play my .flv files
The format .flv actually stands for Flash Video, and unfortunately, this format is only supported by Flash. Previously, Flash would handle the entire video playback. With the introduction of HTML5, it is now handled by the browser or device. Each browser/device has support for its own specific list of codecs. For example, if you embed our HTML5 player in Firefox using just an MP4 file, it will actually fall back to Flash, because Firefox does not support MP4 files in HTML5 (and it probably never will). However, if you embed our HTML5 player using an OGG/OGV file, Firefox will have no problem playing the video back natively in HTML5. Then again, Safari will choke.
4) I am trying to run an RTMP stream with the HTML5 player, but it isn’t working
RTMP is a proprietary streaming technology, developed by Adobe, and it is only supported by Flash. One of the most important things to take note of regarding HTML5 is that it can only support what the browser natively supports. The most common way to view HTML5 video is through progressive download. Progressive download can be compared to simply embedding the Flash player, and pointing to a file on your server.
5) I can't get any of my audio files to play in HTML5
While <video> was the main thing that propelled HTML5 into the limelight, a lot of users have asked about support for MP3 files, and more specially, the <audio> tag. We have this on our radar, and are already planning to incorporate it in the next release of the HTML5 player. In the interim, please note that the current version of the HTML5 player, does not support <audio>.
6) None of Flash Plugins work
The new JW Embedder has the ability for you to specify failover cases, such as first trying HTML5, and then falling back to Flash - or vice versa. Using this same methodology, you can set plugins in the embedder, and when the player is running in Flash mode, the plugins will load.
However, these plugins will not work in HTML5. They are Flash plugins only, thus HTML5 does not support them. But don’t worry, we are working on introducing plugins that work with both Flash and HTML5, so keep your eyes peeled!
7) iPad / iPhone issues regarding skins/player look & feel
When the HTML5 player is played back on an iPad or an iPhone, the result is very simple, it just plays back the video correctly. Nothing else. No bells or whistles. This is because these particular devices use the <video> tag only. Thus, playback will happen in the device’s native video player. For example, the iPhone plays the video back in the QuickTime application - in a new window entirely. This means it does not play directly on the webpage. For the iPad, while the video plays back directly within the webpage, it will still be in the QuickTime application, meaning none of the custom skins, logos, etc. will show up. It won’t look like the JW Player, it will look like a basic video player embedded into a webpage.
8) XML Playlists don't work
HTML5 doesn't support any sort of playlists natively (XML, or any other kind for that matter). Right now, the workaround is to use a JSON playlist instead. In a future release, we will have a workaround for XML playlists, so stay tuned!
Wrapping it Up
I hope this blog post helped clear up some of those remaining questions/misunderstandings that some of you may have about the JW Player 5.3 for Flash and HTML5. If anyone reading still has questions, please feel free to contact us!
Happy Embedding!