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.
The amount of video content on the Internet has exploded over the last few years. This is due in large part to products like the JW Player and services like YouTube and Vimeo. More and more users have come to expect the sites they visit to contain video content. As a result many bloggers are seeing the value in having video content on their site. Not only does it make their site more engaging for their users, it can also be a source of revenue for them through the use of video advertising.
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.
One of the most often asked questions when discussing transcoding is How do I support iPads, iPhones, Blackberries and Android phones?. The goal of this blogpost is to remove some of the mystery behind transcoding for devices and present a solution that will work across a wide range of them.
Many popular video formats, like FLV or WMV, will not play on devices like the iPhone. Even videos encoded in MP4 may not play back, resulting in the following screen:
Error playing video on an iPhone
Doesn't Flash already support hardware acceleration for H.264?
Last week, the W3C held its Second Web & TV Workshop in Berlin. The workshop focused on the convergence of web technology and broadcasting. In other words, how will web and television work together to eventually merge?
Along with sessions on second-screen scenarios and accessibility, the workshops covered adaptive streaming and content protection. Both sessions were very compelling considering that streaming and protection are two important limitations of today's HTML5 video support.
Adaptive Streaming: DASH
Publishing a few on-demand videos can be cheap and simple: just upload the videos to your site and use a tool like the JW Player to embed them on your site. Historically, publishing a live stream has been challenging and a lot more expensive.
The Google Chrome team recently announced it would drop support for the H.264 video codec. Dropping H264 is beneficial for Google in several ways: it may help Google's WebM format gain additional traction in the market and solidifies Google's stance as a supporter of open media formats in the WebM versus H264 debate, as most of Google's other properties (including YouTube) still support H264.
Shortly after the announcement, a truckload of blog posts popped up, explaining the impact this would have on the adoption of WebM over H264. A couple interesting reads:
As you may know, the JW Player has long included support for playing YouTube videos. We did this by integrating YouTube’s ActionScript 2 chromeless player as a JW Player Media Provider, and it has worked well for a number of years. You can see an example of it below. Recently, YouTube made a change to their AS2 chromeless player that affects our ability to support all YouTube videos. This change was announced last October and just went into effect. In short, if you embed a video that YouTube and/or their partners consider monetizable, then the video won’t play and your users will see an error (see the example below).