I decided to just go ahead and make my own thread to discuss this...
I've seen mention in several threads that making responsive player dimensions possible was going to be part of the 6.0 release, but I have not been able to find any examples of how to set that up without breaking some components.
The only examples I've seen are ones that revolve around iframes, etc., which are more hacks than actual support for this feature. I'd like to ensure that there is no accepted way to do this before submitting a feature request.
The most common use case here is expanding to the width of the container, and adjusting the height accordingly. A simple "width: 100%" will fix the first part on the player initialization, but the second requires more work to calculate. The padding percentage trick on a container can give you a correctly sized container to just fill with the player, and maybe that's the best option here, assuming of course all of your videos are the same aspect ratio...
The issue comes in with the positioning of other elements then, and on returning from full screen to normal view (At least for me). In particular, subtitles seem to calculate their position based on the player elements inline style width / height. I can override those in a style sheet with !important and they will still place themselves as if the video is the size specified in those values. So the first step to allowing this would be to revisit the positioning code for subtitles and use a more reliable method of getting the player's height and width.
Second, when returning to the regular size from full screen (At least in Chrome), the video will continue to play but be cropped to the original size of the player instead of resized to fit (This may be a bug with your webkit handling code... I see the webkit transform scale value doesn't change like I would expect it to in this case).
Any comments on these issues, or if I should submit them as bugs or features, etc.?
This should give the desired effect, and it should be pretty obvious from the subtitle positioning that some attention might be needed to make that more robust.
Note: This appears to be an issue with the way the caption renderer is getting the current dimensions of the player when calculating it's position (I'm digging through your source code here).
I would recommend not grabbing that data from the model, as it appears that the model's data is never updated past initial load, and even when it is, it doesn't handle a value of "100%" since the width and height properties of the model are treated as numbers everywhere (And you would have just jammed a string into it).
I would argue that the model width and height should not be relied upon in this case, or there should be a "getWidth" and "getHeight" method that are called from there instead which handle the "100%" value correctly by pulling width and height from the dom instead of the initial config.
Also note, the full screen return seems to also be related to my example too... I notice that it uses the utils.bounds() method to get the resize values here instead of using the model values (which, if it had, I believe would have resized back to the right values).
For some reason in that case, the bounds that it gets are still the fullscreen size bounds (likely due to my "width / height: 100% !important" CSS values... ). This results in only the top left corner of the video playing in the player area.
Note that pausing and playing the video again triggers the video dimensions to reset to the correct size again... which may give some hint as to a fix there.
There are really two issues here: The way subtitles get positioned, and the way return from full screen calculates the original height / width to resize to. I'm assuming you are talking about the second issue.
Neither problem is present when Flash is used instead. So yes, these would be bugs in the HTML5 side of things.
Oh another thing, I noticed when using the Flash version, you add an ID of "videoPlayer_wrapper" to the root element. That would cause some interesting issues I would think with multiple videos on the same page... Would a class not be better here?
Wow, this is a long thread, and I hope I comment to the right questions here:
1) Responsive design (i.e. proportional percentage scaling) is indeed something that’s supported in JW Player. We’re writing a blog post on it – it’ll basically be the same as the grand-old post on A List Apart on this. There’s a catch in that we added a tweak in 6.2 that made this a lot easier. 6.2 gets released Feb 6; the blogpost around that time too.
2) The ID setting shouldn’t be an issue, since “videoPlayer_wrapper” implies you have a div with unique ID called “videoPlayer” on your page.
3) As to the captions positioning, I don’t see any issues, but am on Chrome 24 now. Will do some tests with other browsers….
1. If you have this working, then I'd like to see the CSS attributes you had to add to make it work with 6.1... My example was given above.
2. That would make sense... I had changed the code that output the unique ID to be that static value... Originally it would have been a value like "ctl00$MastHead$ctl00$ctl00$ctl00$dynamicContentListView$ctrl0$VideoPlayer1_videoPlayer" but such an ID appears to break whatever piece of your code is getting that element by ID (I don't think your code likes the $). That was actually a bug I hadn't mentioned yet though, as I hadn't decided if I was instead going to use a different method for generating a unique ID per player.
I'll submit that bug separately though, as it's related to your use of element.querySelectorAll, and the known issues with how that is finicky with otherwise valid ID names.
3. Given my example above? Because I am also on the latest Chrome, and I am seeing two specific issues:
3a. Subtitles are not positioned right. In the ABOVE example, they will be positioned according to a player that is 480px by 270px (The default). If you add a width and height of 100% to the initialization script, they will always be in the upper left hand corner, because the subtitle positioning code assumes that the style will always be an integer, and when you stuff a string like "100%" in it will default assuming a video size of 0x0. 3b. Returning from fullscreen to regular player will not resize the video correctly in the player, so you only see the top left corner of the video playing in the player. This is likely also due to the return from fullscreen not calculating the video size right. Note: Pausing and then playing the video again will fix the video size again, so the resize IS done correctly in that instance.
I have looked at your source code, and there are two DISTINCT issues here.
1. Subtitles do not position correctly when CSS height and width are not specified in player setup. This MAY be related, because it is due to the subtitle positioning being done according to the "Model" values and not according to the ACTUAL video player size. Yes, resizing the player to fullscreen to regular will trigger the model to be updated, but it would seem that the subtitle positioning code is never updated with these new values.
That is RELATED but not the same issue. My issue comes in two flavors, depending on if I specify a height and width in the player setup, or in a separate CSS file overriding the defaults, and BOTH point to this unreliable method that is used to position subtitles. So the fix for my issue is kind of rolled up in that bug report, but fixing that bug may not be sufficient to fix mine.
If you specify a STATIC, PIXEL BASED height and width in player setup, everything works fine. This is because when positioning the subtitles, it looks at the "Model" to get player height and width, which in turn gets its values based on the values that were passed during initial setup (Or defaulting to a given size it appears). If the player changes size (i.e. it is in a responsive design), these values will ALWAYS be incorrect and the subtitles will be positioned according to these static values.
If you instead specify a PERCENTAGE BASED height and width in player setup, it breaks your "Model" method for getting height and width, because it essentially tries to read these values at load time as integers, and fails because you have handed it a string (resulting in you getting height = 1 and width = 1 since the strings are not null). This puts the subtitles in the upper left corner at all times because it thinks the player is 1x1.
In essence: The methods used for subtitle placement are unreliable except in a very proscribed, static usage. I would settle for the subtitle location being recalculated based on the ACTUAL video player size on each display (Not hard, would just mean getting the video player dimensions dynamically instead of relying on Model values to be correct). The other option would be to make subtitle positioning a percentage based calculation, but that may be more trouble than its work.
I don't know if I can describe the issue any clearer than that. I mean I can provide you line numbers and the actual solution, but I thought it best to leave that up to your developers to do.
2. When CSS height and width are not specified in the player setup, returning from fullscreen to regular while playing will cause the player to resize, but the video will not, resulting in only the top left portion of the video being visible in the player.
This one seems to be more related to the manner in which you resize the video on returning to the regular player. As I said, pausing and playing the video again causes it to resize to the right dimensions, so you HAVE the resize code correct in the play method, but incorrect in the return from fullscreen methods. There looked to be some setInterval hacks in that section of code, and I have no idea what they are doing, so I can't prescribe a fix for this one (e.g. it looks like maybe you were trying to get around a "size not available at runtime, so wait half a second and try again" bug).
I CAN prescribe a debugging route though: Use my code above to try this, and in the resize method start logging the actual values you are getting for player size during the resize run. At some point, it is calculating the video size to 100% x 100% of the view port still, when it should be getting the actual video size. This may be a race condition for getting the calculated video player size (Which as I said, it looked like you were trying to handle with a setInterval method).
Both issues are very easy to reproduce given the code I have provided, at least in Chrome (I have not tested in others yet).
Thanks for the detailed feedback, we’ll look into it.
The interval hacks around fullscreen resizing are indeed for issues around dimensions not being available instantly. HTML5 fullscreen support in browsers is still quite “unstable”…
Thank you! I know that the HTML5 video specs are all woefully behind where we would all like them to be, and I appreciate the difficulty in working with all of these different specs as they evolve.
bc.. Second, when returning to the regular size from full screen (At least in Chrome), the video will continue to play but be cropped to the original size of the player instead of resized to fit (This may be a bug with your webkit handling code... I see the webkit transform scale value doesn't change like I would expect it to in this case).
This was a known issue when using Chrome 23 which was corrected in Chrome 24. Chrome 23 was buggy as was the initial release of FF18. FF current release is 18.0.2
The issue yielded skewing of the video to the left and down there was a conflicts with the ESC key and page key events.
I discovered this when I gave the visitor to my web site the choice of viewing in 'fullscreen' or 'normalscreen' mode.
Willie, I'm not sure that is true. I am viewing this in Chrome 24. The video rescaling issue is likely due to one of two issues:
1. The original size of the player isn't available to the video resizing code at the time of execution (e.g. returning from fullscreen triggers its handler BEFORE the browser has recalculated the height and width. 2. The video resizing code WHEN RETURNING FROM FULLSCREEN uses a different resizing method which fails to grab the original height and width of the player when height and width are specified as percentages. Note that pausing and playing again will resize the video correctly again, so THAT RESIZING CODE IS RIGHT, BUT THE RETURNING FROM FULLSCREEN CODE IS WRONG.
Again note: All of these issues revolve around making JWPlayer work in a responsive design. I concur that they may work fine in a static sizing configuration, but attempting to move to a dynamic, responsive solution will break because of the way certain sizing methods have been implemented.
This will result in the videoContainer having the correct responsive dimensions, to which the actual player should then expand to fit. And it DOES, with the exception of the two issues I have mentioned here.
==
Now lets take a look at subtitle positioning. Around line 222 and 227 of jwplayer.html5.captions.js, the subtitle positioning gets the width and height of the current player by calling _api.jwGetWidth and _api.jwGetHeight respectively. Tracing that back through jwplayer.api.js (line 66 and 108), there is an internal call to jwplayer.html5.player.js, which punts the call to jwplayer.html5.model.js. This then looks at the height and width specified in jwplayer.html5.model.js, which _stores these at integers._
Now model get's instantiated with the settings passed during initialization. _If I hand it a percentage based value at init, then this value will be a string and not an integer._
Now rewind back to that positioning code. These values are passed to jwplayer.html5.captions.renderer.js for the resize method to use. Now what happens if you start running math calculations against a string, or setting left and top values to "100%" + "px"? Gibberish, right? And that is the issue here.
*A quick an easy fix might be to make the initialization logic of Model treat height and width differently to CALCULATE the height and width instead of taking what is handed to it directly* In fact, this should probably be done ANYWAY, and could account for someone putting "width: '450px'" instead of "width: 450" as well... just would be a good idea from an error handling standpoint I would think.
That would make sure the model sizes are correct (at load), and subtitle positioning would be right (at load).
<string>If model is supposed to be right at all times though, you have an issue still.</strong> What happens when someone resizes the browser window and your responsive video gets resized in the process? Now the model is again, incorrect, and will continue to display the subtitles in that old, incorrect location instead of moving them to coincide with the new location they should be in based on the players new dimensions.
I see three possibilities for a fix, depending on your architecture and the rules you have in place for these objects:
1. Model's height and width go and get the _real, current_ height and width and return them instead of being static, but this may break other positioning code, depending on what assumptions you make about model throughout your code. 2. The _redraw method in jwplayer.html5.captions.js gets changed to get the real, current values instead of relying on Model being right. This would fix ONLY subtitles, while the previous one might fix the video resize issue as well... 3. Some sort of event gets tagged on to the browser's resize event which will trigger a recalculation of model's height and width on change.
*My recommended approach would be one of the following:*
1. Change model to always return the _current_ calculated height and width of the player. Again, this might cause other issues...
OR
1. Change model's init logic to calculate _initial_ height and width based on ACTUAL calculated dimensions of what is passed to it (if anything). 2.Setup an event handler on the browser window's resize event to trigger a recalculation of the model height and width based on the _current_ dimensions.
Essentially: The original assumption seems to have been "initialize, and then everything is set in stone". That assumption breaks when talking responsive design. So if everything is relying on model's values to be right in order to get the height and width, which it appears they do, then it is model's values which must be made dynamic.
Please forward this tirade on to a developer / make a new ticket item for this. It is PROBABLY related to #1896 to some extent, but my particular issues here are related to using the player in a responsive design, which ticket #1896 doesn't really cover.
I can certainly download and make these changes and such, but I'm just unsure how to contribute the changes back to you...
// This gets added later _model.playlist = []; _model.setItem(0);
_videoTag = document.createElement("video"); _video = new html5.video(_videoTag); _video.volume(_model.volume); _video.mute(_model.mute); _video.addGlobalListener(_videoEventHandler);
var container = document.getElementById(_model.id);
// Get real player dimensions if (isNaN(_model.height)) { var calculatedHeight = utils.parseDimension(_model.height); if (isNaN(calculatedHeight)) { // Percentage based calculatedHeight = utils.bounds(container).height * (calculatedHeight.slice(0, -1) / 100); }
Would get the container element's size and calculate the width / height based on it if a percentage based value is used. A little cleanup to ENSURE its actually a percentage, and maybe a better way to get the container element if you want, and this would be number 1 of my second proposed solution.
This would solve both of MY issues, it just leaves the issue of someone resizing their browser and the video / captions, etc., not resizing with it... that is, this _still assumes a static player after initialization_, but makes it so that the actual size of the initial player doesn't need to be known, but can be calculated at run time instead.
Part 2 of my suggestion would then need to be implemented to handle browser resizing events, but I'm not sure exactly how to do that with your code, as you seem to have a whole event system built up on top of the API. But basically, on resize of the browser, I would think you could just trigger the JWPLAYER_RESIZE event...
Thanks JeroenW. I've supplied the fix above to help your developers out a bit. I would actually prefer that this be made into a new ticket, along the lines of "Allow for dynamic sizing to container", as it really doesn't have anything to do with the captions placement after return from fullscreen, and tying the issues together is going to impede this fix being implemented until that one is.
Markus: Yes that is pretty much what I am doing here. The issue is that this will break caption placement and return from fullsize to normal player dimensions, the first of which are necessary for Section 508 compatibility, and the second being a bug, both of which are fixed with this. My point, and my fix, is that it is better for JWPlayer to support setting width and height to a percentage of the container (e.g. 100%) in the JWPlayer setup. That renders the second CSS rule moot, and the last two can be combined so you get:
Jeroen - any update on your comment about the 6.2 tweak and blog post that will shed some more light on this? I've been wrestling with trying to get the player working responsively. Any improvements to simplify the process would be great!
We did some tests with 6.2, but unfortunately it’s still hard to setup responsively. We’re now looking into making a specific feature out of this, which can be enabled with a single option. Something like:
I have transferred some of this into a feature request, as the "related" tickets have been closed, and this really needs to be its own ticket item.
I like JeroenW's suggestion, though I think a "responsive: true" option would be better. The ratio option would only be necessary if you were going to automatically wrap the video player in a container to achieve this, as you would then have to build the padding percentage dynamically...
An alternative could also be to provide the ORIGINAL height and width, and have the ratio calculated from that, and in conjunction with a "responsive" flag do these things.
Of course, to handle window resizing, you would still need to attach an event handler to window.resize in this case as well, but that's one line of code that can be attached if "responsive" is true...
The BEST option would be to actually support percentage based responsive sizing, but I recognize that with the design decisions that were made early in JWPlayer's creation, that would require a much bigger overhaul of the code, as right now everything is reliant on a static width / height in the model...
The option with providing the original height/width, could work. Then the setup would be something like this:
jwplayer().setup({
width: 320
height: 180
responsive: true
});In this case, the responsive:true option would automatically stretch the player width to 100% of the container div, and the heigh would scale proportionally.What do you mean with "percentage based responsive sizing"? Can you show an example config code? I don't think we have limitations in the player around solely supporting pixel dimensions, so something like this will be possible.
Yeah, that's pretty much what I meant. Of course, you also have to adjust for the playlist bar width if it is enabled, but that isn't hard. My only concern is it takes an established API meaning and redefines it if a flag is used, which isn't exactly good API design... but I leave such decisions up to you guys on what you think makes sense.
Because a lot of your code calls on the Model for getting the current height and width, and because that code seems to always be based around those properties being numeric instead of a string (like a percentage based height / width of "100%" would be), there is a limitation that breaks several things (e.g. in this thread: Caption positioning and return from full screen) when those are not numeric (as strings will be interpreted as 0 or 1 at all times in these cases, so the dimensions reported end up always being 0x0 instead of calculating the actual width based on percentage and returning that).
In that case, I could do height and width of "100%" in the setup, and add my own container for sizing, but as I said, that breaks a couple of things because of the design assumptions JWPlayer makes. In addition, caption placement, etc., would probably need to move to a percentage based top / left value to handle browser window resize events without having to hook window.resize, etc. That would require a pretty major overhaul of your code to find all those.
I think from a feature perspective, your best option is to have a responsive flag that triggers a couple of things:
1. Wrapping the whole player in a container for sizing. 2. Trigger height and width to be 100% of it's container. Note that my hack above is still necessary in that case to make the model support the 100% values! 3. Attach a window.resize event that handles calling resize on the player if necessary (If the browser window shrinks its container past the bounds of the player). This is optional but would really make the player fully responsive.
Thanks for your feedback! Note the smaller issues around captions and controlbar/fullscreen will get fixed in 6.3. These were really bugs.
The issue with a 100% width/height is that we won’t be solving the real problem for publishers: if the width is fluid, the height needs to change proportional. That’s something these CSS scripts using “margin-bottom:55%” generally provide, but it’s quite hacky and not for the uninitiated. Instead, I want JW Player to take care of that problem.
We’ll continue to do some research on available options and see which one will allow for proportionally scaled height while impacting the API as little as possible. However many internal player changes are required is not a problem; as long as the publisher facing bits are optimal.
No problem... these are pieces we need in OUR implementation, and as there seemed to be some confusion in various forum responses as to the ability to do this, I wanted to contribute back the changes we found necessary to make this all work.
Of course, the fact that we have a commercial license contributes too... my custom version is compiled from your source code, which appears to be a fork of the commercial version to add the JWPlayer overlay, etc., which means I don't have a way to turn those off right now... so I kind of have a vested interest to see this rolled in quickly to the commercial version.
For anyone else tagging along, I moved most of this to a feature request: http://www.longtailvideo.com/support/forums/jw-player/feature-suggestions/31411/support-responsive-design-dynamic-sizing#comment-176322
It's really the better place to discuss this at this point as it is going to require upstream changes to facilitate it.
I'm going to post this here as well in case anyone finds this and is looking to do a responsive player before they implement the above feature request:
bc.. jQuery(document).ready(function() { var parentWidth = document.getElementById("videoPlayer_wrapper") != null ? document.getElementById("videoPlayer_wrapper").parentNode.offsetWidth : document.getElementById("videoPlayer").parentNode.offsetWidth; var aspectRatio = 720/1280;
Hey fellas. I realize that it's been less than a month, but I'm currently in the process of developing a video platform for my company, which we'll presumably be using for the next year or so at least. I've been delaying building the player because I was hoping JWplayer would natively support responsive by the time I got around to it.
Do you guys think this feature is coming in the next month, or should I go ahead and build in one of these workarounds with the potential of redoing all of it when the update comes?
In the meantime you may wish to check out my JW HTML Configuration library which makes the basic JW Player responsive.
I'm still to do some work with captions and am currently in the process of documenting the more advanced configuration options (for quality levels & playlists) but it might suit your needs in the short term.
Check it out at: http://powered-by-haiku.co.uk/?p=189
@ James, thank you, that solved the problem. Only 1 minor issue, if I use my own path's to the javascripts, then it won't load. If I replace the links with yours, then it works.
PS: in order to have the YouTube video play in HTML5 mode (and so on iOS) you need to include the bc.. data-youtube="jw5" attribute to the video tag.
_You'll also need to download the latest version of the JW HTML Config library as there was a bug with getting this playing correctly in a non-playlist setup._
@James – That is a good note, data-youtube=“jw5”, didn’t know about that. Your link works well.
@Domingos – Your test page does not work in Firefox at least for me, because this file is missing – http://derrickson.nl/wp-content/themes/derrickson/2013/js/jwplayer.flash.swf
It's solved now, thank you both. It wasn't working because the .swf file wasn't in the /js directory.
@James, yes i'm using the latest jw html config (6.3). Thank you again, because with your script I don't need to use any more css hacks, iframes and fitvidsjs to make jwplayer responsive.
@Domingos - Ultimately the YouTube video will need to be played in a Flash player of some description - whether it is the JW Player, or YouTube's own. The only difference is the YouTube player is coded in such a way to be able to play on iOS devices.
By including the following attribute on the video tag, we are able to force JW6 to use the old JW5 approach for embedding YouTube videos:
bc.. data-youtube="jw5"
In time JW6 may provide a means to embed YouTube videos that play on iOS - in the meantime this is a workaround.
Turning Flash off on the browser will result in both players being unable to operate - there is no way around this unfortunately.
Note: I have just spotted that this technique does not work in Firefox - I'll look at what can be done to resolve this...
James, that's correct, I've testen jwplayer and youtube on several browsers with flash turned off. The player won't work then, except on ios devices and Google Chrome.
Seems like Google has implemented some techniques so that the video's wil play regardless if the flash is turned of in google chrome.
@Domingos - I've updated the JW HTML Config library to take care of the situation where a YouTube source is linked to using JW6, but Flash is not available - the YouTube HTML5 player is now used (assuming the browser supports the original source media format).
If you download the latest version (v1.6.4.1) and link to this in your example page, it should work under this situation.
I've also updated the demo: http://dev.powered-by-haiku.co.uk/jw-html-config/debug/domingos.htm
I've been exploring this further, and as such have now updated the JW HTML Config library to cater for the embedding of Vimeo videos in the same way as YouTube.
We just fail back to the default YouTube player, and Vimeo isn’t even officially supported by us, so these issues might be related to those stock players by these companies…
I've made some tweaks to the JW HTML Config library and borrowed another Android device to test against.
The latest version (v.1.6.6) seems to work in HTML mode with YouTube and Vimeo as follows:
Desktop PC / Mac ============== > Chrome (both work - with / without flash) > Firefox (with / without flash for YouTube - only with flash for Vimeo [as the source is MP4]) > Safari (both work - with / without flash) > Opera (with / without flash for YouTube - only with flash for Vimeo [as the source is MP4]) > IE9+ (both work - with / without flash) > IE8- (with flash for YouTube - not for Vimeo as I can't kick JW Player out of flash mode)
iPhone 4GS / iOS 5.1.1 ================= > Safari (both work fine) > Chrome (both work fine)
iPad v1 / iOS 5.1.1 ============== > Safari (both work fine) > Chrome (both work fine)
Tablet / Android 4.0 ============== > Stock browser (both work fine provided the UAString is set to "Android" - default seemed to be "iPad" in which case only Vimeo worked)
Tablet / Android 4.1.1 ===================== > Stock browser / Chrome (both work fine provided the UAString is set to "Android" - this appears to be the default)
Would be interested in whether this has made any difference in your test environment.
Do they play if you go to the respective sites (YouTube or Vimeo) directly using the same device?
All JW HTML Config does is wrap the YouTube or Vimeo video in a JW style setup. Once the decision has been made on how to present it (either using Flash or HTML5 fallback) the play process is passed through to the service providers own logic.
