by Jeroen Wijering on 2013-03-13 17:18
With over 400,000 downloads and counting, the JW Player for WordPress Plugin is an extremely popular way that our publishers go live. We are now proud to announce the general availability of our WordPress plugin for JW Player 6, as part of the plugin’s 2.0 update. We are excited to have our WordPress users upgrade to our newest major JW Player version - JW Player 6.
Read about what’s new in our WordPress plugin for JW6 and then visit our Getting Started Guide to get JW Player 6 up and running on your WordPress blog.
There’s quite a bit of new functionality in our WordPress Plugin 2.0 update, mostly centered around JW Player 6:
Please note that certain functionality is no longer supported in JW Player 6 when compared with JW5. Some of those key items are ZIP skins, SWF plugins and the playback of JPG/PNG images. Existing WordPress users should read Upgrading Your WordPress Plugin from JW5 to JW6 for more info.
Our deep integration with WordPress has long separated us from other video plugins. In the plugin upgrade for JW6, we have enhanced the player's integration so you can:
See our WordPress Plugin Reference if you’re interested in a full overview of functionality. And note we have made sure that all of this works with the new Media Manager that was introduced in WordPress 3.5.
We very much encourage you to install or upgrade your WordPress plugin and let us know what you think. We are always interested in feedback on items we can improve upon or extend!
One option that is definitely coming soon is an option to have JW Player scale automatically according to the width of the page. This feature will make including JW Player in a Responsive Design setup a breeze.
by Jeroen Wijering on 2012-10-19 11:30
This week we released another quarterly update to our online resource, The State of HTML5 Video Report. Since its launch in January, our HTML5 report has been read over 200,000 times, and is actively discussed on social media and the blogosphere. We eagerly await your feedback on this latest version!
In Q3 2012, there have been some interesting trends in market share both on the browser and mobile sides. We tested HTML5 support in Android 4.1 (Jelly Bean) and found it encouraging on most fronts. In terms of what to look for on the horizon, we are very excited about upcoming text track support and the new MediaSource API for HTML5 adaptive streaming.
The desktop browser and mobile device market continues to shift. On the browser side, Chrome keeps growing, seemingly at the expense of Firefox. IE is mostly stable, with IE9 having overtaken IE8 and IE6/7 almost gone. The two leading mobile devices both grew in overall market share: iOS share increased to 5% and Android share increased to 4%.

A downstream effect of these trends has been to advantage the MP4 video format. 60% of the world now supports MP4 in HTML5, while 50% supports WebM in HTML5. Meanwhile, Firefox works on H264 support, which will further add to MP4’s market lead.
Android 4.1, Jelly Bean, has arrived, and we put it to the test. It came through with very robust HTML5 video support overall. The choice of Chrome as its default browser means near bug-free support and periodical updates.
On the UX side, Android controls are generally more useful (for example, clicking on a poster image now starts the video) and there is smooth switching between windowed and fullscreen playback. Overall, we feel Jelly Bean brings Android’s <video> support on par with iOS.

Unfortunately, Android 4.1 did drop support for Apple’s HTTP Live Streaming protocol, after having introduced it in version 3.0. Since Adobe Flash is also no longer supported, adaptive streaming on Android is a significant a problem. It remains to be seen how Google will approach this going forward.
The maturing of HTML5 technology brings with it continued stability improvements across the board. For example, on Chrome and Safari, the video poster image now stays visible for audio files, and all major browsers except Opera now include a fullscreen button control.
One of the most exciting things rapidly gaining momentum is text track support. As we discussed previously, this goes way beyond captions and subtitles, and promises to revolutionize video navigation and search as well. Only Safari 6 supports text track for now, but it is soon to come in IE10, Chrome23 and Opera 12.5. Only Firefox is not actively working on it.
Another development to watch is the new Media Source Extensions. Co-authored by Microsoft and Google, this will allow adaptive streaming in HTML5, among other use cases, via an API similar to Flash. Chrome and Opera are working on implementations.
With a declining market share, no news on MP4 / <track> / MediaSource, and no significant mobile presence, the future does not look great for Firefox. This is unfortunate for Mozilla, but also for innovation and online standards. A diverse browser landscape with several major rendering engines is to the benefit of all.
There is still a lot of great stuff coming from Mozilla (like Opus - the free audio codec), so hopefully they’ll be able to reverse this trend and put Firefox back on <track> ;).
We hope that you’ll read our full report The State of HTML5 Video and join our discussion! We’ll be responding to comments on this blogpost and on our Facebook page.
by Jeroen Wijering on 2012-09-06 10:15
FOMS (Foundations of Open Media Software) is an annual unconference for media engineers, known for its attitude of getting things done. This year's edition - held in Paris, France - again had a great mix of attendees representing codec manufacturers, media frameworks, web browsers and video players.

On the web browser side, the biggest topic was the implementation of
At FOMS, both Opera and Chrome demoed working text track implementations. For Opera, this functionality will probably ship with version 12.5, while Chrome users have to wait until version 23. Safari 6 and Internet Explorer 10 will have
Despite all the progress and working implementations, the WebVTT specification is not yet done. Current outstanding issues are the implementation of roll-up captions (for live broadcasting, like this example) and the ability to store CSS in WebVTT - for players like VLC or Flash, who cannot access the webpage. Both items were heavily discussed during the workshop and proposals for implementation were filed with W3C.

Though captions in themselves are great, HTML5 Text Tracks can do a lot more. At FOMS, we saw several demos to show applications of WebVTT beyond captions. The demos we presented are listed below.
Note: you need a browser with text track support to see the demos:
![]()
Another interesting subject at FOMS was the implementation of adaptive streaming in JavaScript. A team of Chrome engineers presented a new demo of the Media Source API, which allows the appending of arbitrary chunks of video to an already playing stream. As we noted in our HTML5 progress update last year, web developers can use this API to create adaptive streaming applications, using fMP4 or WebM video fragments (TS may be coming too, for anyone interested in building HLS support in HTML5). The API can be enabled in Chrome 23 using chrome://flags.
Many other interesting developments, like the new OPUS audio codec and EME content protection scheme, were covered. The FOMS website contains the detailed notes for all of our sessions. In summary, it became clear at FOMS 2012 that so much is going on in the open media scene, and many great tools are yet to come.
by Jeroen Wijering on 2012-04-19 10:00
In January 2012, we announced the launch of our online resource, The State of HTML5 Video Report. Since its launch, we have had a tremendous response from our community. The page itself has been tweeted over 3,000 times, received 30,000 visits the day of its launch, and is still actively circulating the digital sphere.
Three months after its initial launch, we have updated the report with some very interesting findings. First, you will find a new JavaScript section, dedicated to video scripting using the video tag. Common use cases for this are the rendering of custom controls (like JW Player does) or page interaction with the video timeline (like Popcorn.js does). Second, you will find all existing tests updated with results from the latest browsers and mobile platforms. We highlight some interesting findings below.
Compared with our statistics from last quarter, we already see shifts in market share. By market share, we mean the portion of the online market that is controlled by a particular browser / device:
IE 6/7/8 are declining quickly; their market share has gone from approximately 28% to 22% in the last few months. IE9, however, is growing (up to 11% market share from 9%). Chrome & Firefox are growing as well. Both have surpassed the share of IE 6/7/8.
Additionally, Android now has surpassed Opera. In terms of the mobile market, iOS still controls roughly 2x (4%) more than the other platforms, due to its dominance over the tablet market & recent success with the iPhone 4S. Other mobile platforms are virtually nonexistent.
While Android 4.0 (Ice Cream Sandwich) was released last year, not every device-maker has updated their devices to the latest operating system. Still, some devices (like the Galaxy S2) now run ICS, so we have included it in our test results. Unfortunately, we found Android 4.0 to exist as a mixed bag of new features and new bugs. Some of the more interesting findings were:
There have been several updates on the state of Fullscreen playback in HTML5, which is pretty exciting for online video. While Chrome & Safari already supported the Fullscreen API, Firefox recently introduced support for it too (view our test page here). Thus, between these three browsers, the majority of the browser market supports fullscreen playback in HTML5. Opera is actively working on fullscreen support; presumably IE10 will introduce beta support as well.
Other interesting developments that you should stay tuned for more information on include Firefox's drop in support for the fullscreen button, and the discussion around fullscreen support in mobile devices, which becomes more relevant now that Android 4.0 plays the video inline.
We hope you take a look at the most recent version of our published report, share with your community, and send us your feedback! Feel free to post your comments directly to this blogpost, or join the discussion on our Facebook page.
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.
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.
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:
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.
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.
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.