Blog Archives: October 2010
JW Player 5.3, HTML5, and You
by Ethan Feldman on 2010-10-28 10:54
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!
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.
FOMS: Funny Name, Serious Talk about HTML5, Bitrate Switching, WebM, and WebSRT
by Zachary Ozer on 2010-10-08 13:25
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.
Follow us on Twitter: 