When it comes to embedded media on the web, the JW Player from LongTail Video<\/a> is widely regarded as one of the best solutions in terms of producing consistent results across a wide range of browsers and devices.<\/strong><\/p>\n \nSince release 5.3, JW Player has included a specific embedding method that caters for the creation of a video player with seamless failover between Flash and HTML5 modes (and vice versa). It also introduced the ability to use the parameters defined in HTML5 In my role as Web Developer for a large UK organisation, I recently tasked myself with writing an extension to the JW Player solution with the primary aim of simplifying the configuration process (particularly in relation to playlists) whilst additionally producing an output that reacts responsively. The aim was to provide a solution which doesn’t require additional, separate JavaScript configuration – all settings are to be driven from simple inline HTML.\n<\/p>\n \nIn much the same way the JW Embedder uses the principle of progressive enhancement by interrogating the HTML5 \nDuring the development of this extension (which takes the form of a small JavaScript library, and details can be found here<\/a><\/em>) I encountered a number of “setup and playback inconsistencies” which, when checking in the JW Player forums, became clear I was not alone in experiencing. These “unexplained hiccups” appear to be increasingly common and a worrying source of frustration for users who are implementing (or more likely updating) JW Player to make use of the more elegant and accessible HTML5 first approach.\n<\/p>\n To understand more about how these frustrations manifest themselves – let\u2019s explore a likely route to JW Player\/HTML5 implementation :<\/p>\n \nOk. Let’s say for arguments sake I have some experience in implementing JW Player, going back to before 5.3, when I happily managed to get MP4 videos playing on my website using the Flash embed method. Life is sweet! A single video format played through a 3rd party plugin. If you don’t have the plugin, you don’t get the video – that’s just the way it is I’m afraid!\n<\/p>\n [Time passes by]<\/p>\n \nNow I’ve been thinking, maybe my website should make more of an effort to cater for a wider audience and start supporting HTML5 video – specifically to serve those Flash intolerant devices! No problem. As I understand it these devices support MP4 video natively, so all I need to do is upgrade to the latest version of JW Player (let\u2019s say 5.7) and let it handle the Flash to HTML5 failover as required. Perfect.\n<\/p>\n \nErm… or maybe not! It seems that my MP4 video files don’t actually play on the latest iDevices. After a mild panic, and a little bit of research, I am able to figure out that while it seems Flash is quite forgiving about the encoding of video, the iDevice is not. Resolving the problem involves re-encoding the videos specifically for the iDevice, which although a bit of a headache, is perfectly manageable and the result is worth it.\n<\/p>\n [More time passes]<\/p>\n \nAs my understanding of my website audience evolves further, and my desire to reach as many different users – on a broad range of devices – becomes a key objective, I decide to switch my video strategy to serve HTML5 first with a Flash fall-back.\n<\/p>\n \nAfter a bit of research, I decide that the best approach (involving the least effort) involves simply switching my JW Embed method to make use of the native \nOne change I make to this code is to place the \nThis in theory caters for the base position of native playback in all the mainstream browsers (Firefox & Opera \u2013 playing WebM; IE9, iOS, Safari & Android \u2013 playing MP4; Chrome – playing MP4 or WebM).\n<\/p>\n \nIt also has the benefit that if JavaScript is enabled, JW Player will progressively enhance the player to ensure a consistent look-and-feel across all these browsers, plus provide a Flash fall-back for earlier versions of IE \u2013 playing the MP4.\n<\/p>\n \nWell that wasn\u2019t too hard to implement\u2026 Except\u2026 What the\u2026?!\n<\/p>\n \nAfter testing thoroughly and ensuring the videos play in all the browsers as expected I push my site live and I am greeted with\u2026 issues. Not only that, the worse kind of issues \u2013 inconsistent issues.\n<\/p>\n \nA selection of problems encountered include:\n<\/p>\n \nGiven the specific nature of these issues, they should<\/em> be reasonably easy to debug and determine a solution to.\n<\/p>\n \nHowever the following \u201cgeneric\u201d issues have also been experienced. These are much less obvious in terms of cause and can end up being responsible for hours of debugging frustration:\n<\/p>\n \nNow, there are a number of phrases that might be used to describe this situation – the most likely in a business context being \u201cshow-stopper\u201d. This may quickly be followed by the dreaded question \u201cIs this the right solution for us?\u201d.\n<\/p>\n \nIn my opinion JW Player is indeed a very good solution – the support forums are a great means for getting issues resolved, and there is usually willing assistance with helping you understand the complexities of producing video for the web. However, as with many situations, knowing what question to ask in this context can sometimes make the difference between getting a speedy resolution versus a gradual increase in grey hairs and heightened blood pressure!\n<\/p>\n \nHaving experienced a number of these issues first-hand, and worked through them, I thought it would be useful to share my findings. The following pointers should cover off the specific issues detailed above and will also cater for some of the \u201cgeneric\u201d issues:\n<\/p>\n \nOne of the most common stumbling blocks (and therefore most likely to resolve issues) is ensuring the encoding used is correct. It has been said many times before and I\u2019m sure it will be said again – encoding is key. This is particularly relevant when it comes to producing an MP4 which is intended for playback on multiple devices \u2013 desktop browsers, iDevices, Android phones\/tablets and recent Blackberry phones.\n<\/p>\n \nAccording to the JW Player documentation, the following specification should be adhered to:\n<\/p>\n \n> Container format: MP4, headers at the beginning of the file (for seeking) \nAlso, within the support forums you will regularly see advice to \u201cencode video to H.264 using Handbrake\u201d and the JW documentation continues to say:\n<\/p>\n Handbrake has a built-in present called iPhone & iPod Touch, which has exactly the right settings.<\/p><\/blockquote>\n Whilst good advice, this actually falls short of ensuring you get the correct results. One important option that is unchecked by default<\/strong> in all Handbrake profiles is the \u201cWeb optimized\u201d option. Selecting this option reorders some of the metadata within the encoded video to the start of the container. This ensures the video can stream and allows the user to jump to specific points while the rest is downloading in the background.\n<\/p>\n \nIf the metadata appears at the end of the video, the whole file needs to be downloaded before the video will start playing. I therefore highly recommend checking the \u201cWeb optimised\u201d option when you encode. If you have files that are already encoded and are concerned that the metadata is not at the start, you can use another tool such as qt-faststart<\/a> to move the metadata retrospectively.\n<\/p>\n \nMore recent versions of Handbrake include the \u201ciPhone 4\u201d, \u201ciPad\u201d & \u201cAppleTV\u201d profiles which have the \u201cLarge file size\u201d option checked by default. They also include the \u201cMaximum B-Frames\u201d set to \u201c3\u201d along with a host of other default settings. I would advise considering these settings further when deciding which profile to use.\n<\/p>\n \nFor further detail regarding HTML5 video support, encoding options and much more useful information check out the excellent \u201cVideo on the Web\u201d<\/a> resource by Mark Pilgrim\n<\/p>\n \nFor video to be correctly rendered in WebKit based browsers, the MIME-type provided by the server must correctly correspond to the encoding used.<\/p>\n Specifically:<\/p>\n \nIn terms of what to include in the \nIf you experience problems with MP4 video playing on earlier version of Android you may wish to explore removing the \nIn a bid to try and save bandwidth, some web hosts will gzip everything by default – including video files. In Firefox and Opera, seeking will not be possible or the video may not play at all if a video file is gzipped. If this is occurring it would be prudent to check your server \/ hosts and disable the gzipping of media files.\n<\/p>\n \nIt goes without saying that in order to play video via the Flash player, the browser needs to have the Flash plugin installed. Don\u2019t assume this is the case for all browsers and try to provide a positive fall-back option \u2013 this also helps to debug issues.\n<\/p>\n Flash v9+ is required to playback H.264 encoded MP4\u2019s.<\/p>\n \nA less obvious gotcha is the dependency of Quicktime for Safari when playing native video on Windows. Again support for this comes via a plugin, which is commonly not installed. Failure to have this available, plus the lack of the Flash plugin can actually lead to no player being rendered in Safari.\n<\/p>\n \nIE7 & IE8 don’t understand the native \nFirstly the Flash plugin needs to be available.<\/p>\n \nSecondly the use of a HTML5 Shim in order to \u201cregister\u201d the availability of the \nThe following parameters and their impact can often be overlooked when it comes to implementing a native \nautoplay () : include this attribute (no value) to let the video start as the page gets loaded. Use sparsely, since this may frustrate your viewers. Note that it does not work on iOS. \nThe JW Documentation also states:\n<\/p>\n \n\u2026 Plus there’s the inevitable browser bugs (especially on devices) and different looking controls that cannot be styled.<\/p>\n The JW Player helps to fix all these issues. It sniffs out the contents of the video tag – the sources, as well as the poster, loop, autoplay, etc.). It also detects the browser capabilities and then uses JavaScript to, for example, work around bugs, add new features or embed a Flash version of the player in place of the tag.\n<\/p><\/blockquote>\n \nGiven these statements you might expect the \nSadly this is not the case. Furthermore, these seemingly supplementary attributes are the reason behind most of the unexplainable \u201cgeneric\u201d issues detailed above.\n<\/p>\n \nFirstly it\u2019s important to note that, contrary to what is stated, JW Player does not directly make use of these parameters.\n<\/p>\n \nIt does have similar acting parameters which can only be included as part of the JavaScript setup configuration ( \nThe second part of this is understandable as the JW Player needs to override the browsers built in functionality with it’s own implementation in order to provide consistency.\n<\/p>\n \nIf JW Player determines that it should render in HTML5 mode, then it simply creates an empty video tag stub<\/em> with none of these attributes included. This is because it also doesn’t set the \nComing back to the first part, why not allow the attributes to act as the configuration settings for the JW Player – even if they ultimately translate to JW’s own implementation? Surely this is a bug… Actually I believe it’s an oversight that LongTail Video are happy to brush under the carpet.\n<\/p>\n \nLets update my original code with these parameters and work through what happens:\n<\/p>\n \nThe most obvious thing to note given this configuration is that the native \nThen when the JW Player library is loaded and the \n[*]<\/strong> Depending on what follows the \nClearly this doesn’t result in a great user experience and depending on your requirements\/flexibility there are things that can be done to make it better, however it does raise an interesting question – what *actually*<\/strong> happens to the video that is already playing when JW overwrites it?\n<\/p>\n \nYou may rightly expect either the browser, or the JW embed process, to handle the clean up of the existing video – removing it from the DOM and wiping clean any future demands the resource may have on the browser, network or memory… You might therefore be surprised to learn that this is not the case!<\/strong>\n<\/p>\n \nThrough my testing (yes – I ended up building a video testbed<\/em>) I was able to determine the following:\n<\/p>\n \nIf the native video is given enough time[1]<\/strong> to start doing “stuff”[2]<\/strong> before it is wiped out by the JW Embed process, the video will continue to exist in memory, can continue to make demands on the network and amazingly may even continue to play.\n<\/p>\n \n[1]<\/strong> Typically I found this to be anything over 0.5 sec. \nThe result of this situation leads to all manner of problems. I have actually seen, and more importantly can reproduce, the “phantom video” causing the following:\n<\/p>\n \nBecause the manifestation of these issues is closely related to the time taken between rendering a native \nWhen you consider the negative impact \nYou may deduce that it’s as simple as to not include<\/strong> the video<\/code> and source<\/code> tag attributes as the default configuration options for setting up the player. This means that once the JW Player JavaScript library has been loaded in the page, a JW Player instance can be generated using a simple video<\/code> tag and zero extra JavaScript – an excellent enhancement to ensure the widest availability of video regardless of a user\u2019s individual browser configuration.\n<\/p>\nJW HTML CONFIG<\/h3>\n
video<\/code> tag and attributes and then dynamically producing a configuration object, which is used as the basis for the player setup, the solution makes use of additional structured settings blocks (tags with data-<\/code> attributes) to extend this concept further.\n<\/p>\nUNEXPLAINED HICCUPS<\/h3>\n
video<\/code> and source<\/code> tags and providing a WebM version of the video – to cater for native playback in Firefox & Opera. I also update JW Player to version 5.10 and specifically include the modes<\/code> block in my setup object – telling it to use html5<\/code> mode first. This is as described in the JW Player documentation:\n<\/p>\n<script src=\"\/jwplayer\/jwplayer.js\" type=\"text\/javascript\"><\/script>
\n<video height=\"270\" width=\"480\" id=\"myVideo\">
\n<source src=\"\/static\/bunny.mp4\" type=\"video\/mp4\">
\n<source src=\"\/static\/bunny.webm\" type=\"video\/webm\">
\n<\/video>
\n<script type=\"text\/javascript\">
\n\/\/ <![CDATA[
\n jwplayer(\"myVideo\").setup(
\n{ modes:
\n[
\n{ type: 'html5' },
\n{ type: 'flash', src: '\/jwplayer\/player.swf' }
\n]
\n});
\n\/\/ ]]>
\n<\/script><\/code><\/p>\nscript<\/code> tags at the bottom of the body<\/code> \u2013 as this is commonly best practice right?! My code now looks like this:\n<\/p>\n<html>
\n<head>
\n\u2026
\n<\/head>
\n<body>
\n<!-- Navigation stuff -->
\n\u2026
\n<!-- Content Area -->
\n<h2>Check this HTML5 video out!<\/h2>
\n<video height=\"270\" width=\"480\" id=\"myVideo\">
\n<source src=\"\/static\/bunny.mp4\" type=\"video\/mp4\">
\n<source src=\"\/static\/bunny.webm\" type=\"video\/webm\">
\n<\/video>
\n<!-- More content -->
\n\u2026
\n<!-- Right hand column -->
\n\u2026
\n<!-- Footer stuff -->
\n<script src=\"\/jwplayer\/jwplayer.js\" type=\"text\/javascript\"><\/script>
\n<script type=\"text\/javascript\">
\n\/\/ <![CDATA[
\n jwplayer(\"myVideo\").setup(
\n{ modes:
\n[
\n{ type: 'html5' },
\n{ type: 'flash', src: '\/jwplayer\/player.swf' }
\n]
\n});
\n\/\/ ]]>
\n<\/script>
\n<\/body>
\n<\/html>
\n<\/code><\/p>\n\n
\n
TIME FOR SOME FOR ANSWERS<\/h3>\n
ENCODING<\/h4>\n
\n> Video format: H.264, Baseline profile, 480×270 pixels, around 400\/600 kbps (kilobits per second)
\n> Audio format: AAC, Low Complexity profile, 44.1 kHz stereo, 96 kbps\n<\/p><\/blockquote>\nSERVER SETTINGS – MIME-TYPES & GZIP<\/h4>\n
MIME-TYPES<\/h5>\n
\n
type<\/code> attribute of the HTML source<\/code> tag, I would suggest only including the MIME-type string \u2013 don\u2019t bother with the \u201ccodecs\u201d element as this is largely ignored anyway. Note: Including the MIME-type here DOES NOT negate the need to have the server configured correctly \u2013 they are not related.<\/strong>\n<\/p>\ntype<\/code> attribute for the MP4 source \u2013 as suggested in Peter Gasston\u2019s post.<\/a>\n<\/p>\nGZIP<\/h5>\n
QUICKTIME & FLASH<\/h4>\n
IE SPECIFICS<\/h4>\n
video<\/code> & source<\/code> tags and so will fall-back to Flash mode. However there are two factors that need to be in place in order for this to happen:\n<\/p>\nvideo<\/code> tag. JW Player cannot interrogate and build a configuration object if the video<\/code> tag has not been \u201cmodernised\u201d. This can be done by including a 3rd party HTML5 Shim library or more sensibly by loading the JW Player library in the head<\/strong> \u2013 JW Player will modernise the video<\/code> tag if needed.\n<\/p>\nADDITIONAL VIDEO PARAMETERS<\/h4>\n
video<\/code> tag in conjunction with JW Player:\n<\/p>\n
\ncontrols () : include this attribute (no value) to display a simple controlbar, provided by the browser. The design of this controlbar varies per browser (which is a common issue JW Player resolves gracefully).
\nheight (number) : height of the video on the page in pixels – is required.
\nloop (): Include this attribute to let the browser continuously repeat playback of the video.
\nposter (string): the url of a poster frame that is shown before the video starts. Can be any PNG, JPG or GIF image. By default, it is not set (i.e. no preview).
\npreload (‘auto’, ‘metadata’, ‘none’) : This attribute defines whether the entire video is loaded upon webpage load, or whether only the metadata is initially loaded. Or, you can choose to not load the video at all upon webpage load. The default (on most browsers) is metadata.
\nsrc (string) : The URL of the video to play. This is not required, since source files can also be listed using tags.
\nwidth (number) : width of the video on the page, in pixels. Is required.\n<\/p><\/blockquote>\ncontrols<\/code>, autoplay<\/code>, loop<\/code> and preload<\/code> attributes to be directly controllable via the video<\/code> tag and for the results to be consistent across browsers\/devices.\n<\/p>\ncontrolbar<\/code>, autostart<\/code>, repeat<\/code> and bufferlength<\/code>) but these are not derived from the original parameters and are also not directly included as part of the newly generated JW video<\/code> tag – they are implemented through pseudo JavaScript methods.\n<\/p>\nsource<\/code> of the video (or src<\/code> in the case of a single playable video or playlist file) until the user clicks the play button (or the file link in the playlist).\n<\/p>\nDIGGING A BIT DEEPER<\/h5>\n
<html>
\n<head>
\n\u2026
\n<\/head>
\n<body>
\n<!-- Navigation stuff -->
\n\u2026
\n<!-- Content Area -->
\n\t<h2>Check this HTML5 video out!<\/h2>
\n\t<video height=\"270\" width=\"480\" id=\"myVideo\" preload=\"auto\" controls autoplay>
\n\t\t<source src=\"\/static\/bunny.mp4\" type=\"video\/mp4\">
\n\t\t<source src=\"\/static\/bunny.webm\" type=\"video\/webm\">
\n\t<\/video>
\n<!-- More content -->
\n\u2026
\n<!-- Right hand column -->
\n\u2026
\n<!-- Footer stuff -->
\n<script src=\"\/jwplayer\/jwplayer.js\" type=\"text\/javascript\"><\/script>
\n<script type=\"text\/javascript\">
\n\/\/ <![CDATA[
\n\tjwplayer(\"myVideo\").setup(
\n\t{
\n\t\tmodes:
\n\t\t[
\n\t\t\t{ type: 'html5' },
\n\t\t\t{ type: 'flash', src: '\/jwplayer\/player.swf' }
\n\t\t]
\n\t});
\n\/\/ ]]>
\n<\/script>
\n<\/body>
\n<\/html>
\n<\/code><\/p>\nvideo<\/code> tag will be interpreted and rendered well before the JW Player library is loaded and the setup<\/code> call is made. This will result in the following:\n<\/p>\n\n
width<\/code> & height<\/code> specified<\/li>\ncontrols<\/code> being displayed over the video<\/li>\npreload<\/code> setting<\/li>\nsetup<\/code> call is made[*]<\/strong> the following will happen:\n<\/p>\n\n
video<\/code> tag with it’s own player furniture comprising a number of nested div<\/code> tags and a new, empty video<\/code> tag<\/li>\nposter<\/code> image will be displayed<\/li>\nposter<\/code> image<\/li>\nvideo<\/code> will not automatically start to play<\/li>\n<\/ol>\nvideo<\/code> tag in the rest of the page – how long it takes to be rendered, and in the case of external scripts, how much they block – this could potentially be a number of seconds later.\n<\/p>\n
\n[2]<\/strong> Either buffering data as a result of the preload<\/code> attribute being set (or more likely not being set – see below<\/em>) or downloading and playing as a result of the autoplay<\/code> attribute.\n<\/p>\n\n
video<\/code> tag on the page and the JW Embedder overwriting it, you can now start to see how a page that one day has a working video, might suddenly start to exhibit inconsistent behaviour – maybe an external script library is blocking just a bit longer than normal (jQuery on a CDN for example<\/em>) or you’ve upgraded to a new version of JW Player and the files are not cached the first time you revisit the page.\n<\/p>\npreload<\/code> and autoplay<\/code> can have depending on your embedding approach, coupled with the fact these two attributes are not respected on the majority of mobile devices it becomes “understandable” why LongTail Video might prefer you not to use them – it just would be nice if the documentation were to accurately reflect this.\n<\/p>\nAND THE SOLUTION?<\/h4>\n
preload<\/code> or autoplay<\/code> attributes in the native video<\/code> tag. However when checking the current default values for preload<\/code> (in the case that you don’t specify the attribute) I found the following:<\/p>\n