Responsive Sizing

[heff]

Responsive sizing is when the player can dynamically change size to fit its container while maintaining the desired aspect ratio. This should be a feature built into video.js and we need to find out the right way to add it. (it's currently possible with additional work or outside libs)

To finish

• Tests written
• Feature implemented
• Docs/guides updated
• Example created (e.g. jsbin)
• Pull request submitted

Related issues: #771, #359, #384, #925, #983
Also see the intrinsic ratio example from @baloneysandwiches

Related Links:
http://alistapart.com/article/creating-intrinsic-ratios-for-video/

The intrinsic ratio method seems like the best approach. In order to make that happen, we need to allow the user to supply the ratio some how. Some potential options:

// set a flag and then we calculate the ratio from the width and height
videojs('id', { responsive: true, width: 1600, height: 900 }); // --> ratio = 16:9

// provide a ratio
videojs('id', { aspectRatio: '16:9' });

(specific naming TBD)

Video.js would essentially have 2 layout modes, fixed and responsive, and we would probably apply a different class of styles to the player div depending on which was needed.

Additional considerations

• How this might affect poster sizing
• What happens if width('600') is called on the player when in responsive mode?
• Determining the aspect ratio after the metadata loads from videoWidth/videoHeight. (We don't support this yet with the fixed layout, so should probably be a separate issue.)

User Stories Draft

Not sure if all of these are valid, but providing possible solutions for each based on the aspectRatio/autoHeight setting.

User wants the video to fill width, and specifies an aspect ratio to calculate height
  `videojs({ aspectRatio: '16:9' });`
    -> Add width: 100%, padding-bottom: (9/16)%

User wants the video to fill width, and auto adjust height to match source aspect ratio from metadata
  `videojs({ aspectRatio: 'auto' });`
    Before metadata:
      Use a default aspect ratio, like 2:1 or 16:9
      -> Add width: 100%, padding-bottom: (9/16)%
    After loadedmetadata
      -> update padding to match source aspect ratio

User wants the video to fill height, and specifies an aspect ratio to calculate width?
  I don't think this is a valid user story, or at least I can't think of a real world use case. Video dimensions are rarely taller than wide (though...iPhone videos). Browser windows have restricted widths not heights.

User wants the video to fill both width and height and the video content to fit inside
  This isn't something we need to handle with this story, but we also don't want to get in the way of it
  `vjs-fill` or a similar simple class to add. Don't need an option.
  --> We would just need to add width: 100%, height: 100%.

User wants the video to fill both width and height and the content to cover the space
  See BigVideo.js. Appears to require a good amount of work. Not something we need to get into with this, and probably best handled as a plugin

User wants a fixed width and height
  `videojs({ width: 100, height: 100 });`

User wants a fixed width and specifies an aspect ratio to calculate height
  `videojs({ width: 100, aspectRatio: '16:9' });
  You could just calucalate height here, so this doesn't seem like a priority.
  If we don't allow this, we could assume whenever aspectRatio is used that we set width to 100%. Otherwise we would just manually calculate the other value here.
  When you do set a width, you can't use the intrinsic ratio, because the height percentage is based on the width of the parent element, not the video player width itself.

User wants a fixed width, and auto adjust height to match source aspect ratio from metadata  
  The video element does this, so video.js should if possible.
  `videojs({ width: 100 });`
  We could either have a default aspect ratio that we calculated and set until the metadata is available, or just allow the default height (set on the .video-js class) to be maintained. The former would be cleaner and more inline with the video element, but would take more work.

User wants a fixed height, and auto adjust width to match source aspect ratio from metadata
  The video element does this also, so video.js should if possible
 `videojs({ height: 100 });`

User wants a video tag with no width or height or aspect ratio settings to be viewable
  `videojs({});`
  We could have a default width/height on the main .video-js class. That way it would be overrideable through CSS or through javascript style setting.

User wants to use CSS to manually set width/height
  `videojs({});` CSS set elsewhere
  The main difference between video.js and the video element here is that with the video element, if you set width and height attributes on the tag, they can easily be overridden by CSS. In Video.js we have to take the width/height attributes and apply them through javascript (inline) styles, which makes them only overrideable by using !important. It should atleast be possible to exclude width/height and use CSS manually.

[albell]

“autoHeight” might be more descriptive. “Responsive” can mean all sorts of things, including calculating width based on height. What we’re talking about here is specifically calculating height based on width, in a typical column-layout. Providing one option is also terser than specifying three:

videojs('id', { autoHeight: '16:9' }); // use provided ratio regardless of metadata
videojs('id', { autoHeight: true}); // derive aspectRatio from metadata
videojs('id', { autoHeight: ''}); // turns off autoHeight
videojs('id', { autoHeight: false}); // turns off autoHeight

videojs('id', { autoHeight: true, height: 300}); // height option ignored in autoHeight mode
videojs('id', { autoHeight: true, width: 500});  // width is respected as usual

Poster sizing should be unaffected.

[jgubman]

FWIW, we've been using a variation on the "intrinsic ratio method" with videojs for several months and it's been great. Examples at:
http://www.funnyordie.com/videos/fa1420df1f/green-team-from-will-ferrell-adam-ghost-panther-mckay-and-john-c-reilly
http://www.funnyordie.com/videos/ca8e174a54/between-two-ferns-with-zach-galifianakis-justin-bieber

We played with keeping things in their native aspect ratio but 4:3 videos were just too massive on wider browser widths, so we lock everything down to 16:9.

I'd vote for "aspectRatio" for the config item. Makes the most sense to me.

[heff]

Thanks @jgubman, that's interesting to know about 4:3 videos.

I agree with @baloneysandwiches that 'responsive' is too vague. I don't love the idea of having both height and autoHeight options. That feels a little confusing.

I created a number of user stories and added them to the body of the issue. It at least helped me wrap my mind around the full problem set better.

There's essentially two things we need to know from the user:
Q1. Are you using this in a fluid/responsive layout?
YES: we'll set the width of the player to 100% and set heights using padding (intrinsic ratio)
NO: we will set width and height in pixels
(we can't use the intrinsic ratio when the width is set in pixels. The percentage used for height is calculated from the width of the parent element of the player, not the width of the player itself)

Q1. Do you have a specific aspect ratio you want?
YES: We'll match that ratio when setting any missing dimension values
NO: We'll provide a default and attempt to read from metadata once it's available

An alternative option I'm consider is fluid. videojs({ fluid: true }); or videojs({ fluid: '16:9' }); If we use aspectRatio/autoHeight, we either assume a fluid layout, or do logic to try to be smart about when it's fixed vs fluid. Since we can't set the height the same between fluid and fixed layouts, it's really important to know first which type of layout we're working with, so that makes me lean towards that as the option name.

[albell]

I find the use case for calculating width based on fixed height to be somewhat obscure, given current layout patterns in the wild, but since the video element supports that, it agree would be nice to address as well for future layout flexibility. “aspectRatio” has the advantage of neutrally addressing the fixed height, flexible width use case.

I think it would great if there were a way to avoid the two-layout-modes thing. That’s tricky. I think what emerges from the above range of use cases is that “responsive” should not be a specialized mode, but the norm. Can the fixed width cases can be built around a default “fluid” code structure?

For example in the “fixed height, known aspect ratio” use case:

videojs('id', { aspectRatio: 16:9, height: 300});

It would be ideal to set a fixed CSS width, based on a little algebra, and still use padding-top to give the player height. In other words, we would never leave “fluid” mode, because there is only fluid mode.

The big obstacle to this, as you point out, is that percentage padding refers to the parent. So if you want a fixed dimension, you need another wrapping parent element to apply the style too. This was the hiccup all the way back in Thierry’s original demo. Yeah, it’s ugly, div-itis, etc, but it simplifies the problem greatly. Are you willing to consider an additional default wrapping div?

[heff]

It would make things a little easier if we could default to fluid. Then any time width/height was set you could drop out of fluid mode. But part of the goal of video.js is to work just like the video element. I made this jsbin earlier to see exactly how the element works by default. It would also be a pretty big change from existing versions, so we'd probably have to delay the change until 5.0.

I'd definitely prefer to avoid adding another wrapper div, especially if that would be the default.

[heff]

One other note is that a fluid width video isn't exactly the best for performance and quality. Increasing or decreasing the size of the video from its actual dimensions makes the decoder do extra work and degrades the quality. This happens all the time with full screen video, but still, it's best to display the video at its actual size, which is what the video element does by default.

If we were to default to fluid, I don't know if there's a good way to auto set the width/height from the metadata. Maybe width=auto height=auto. That's similar to what we have now, and it's not great.

[albell]

I agree that things look best (and perform best) at their encoded size. That’s a good pointer to put in the docs. Also, it should inform how the “null options object” case is handled:

videojs('id', {});
// No supplied height, width, or aspectRatio = handle as a special case.
// Set a default aspectRatio until metadata loads.
// (Essentially, aspectRatio defaults to true.)
// When metadata loads, set width from metadata,
// and set padding-top based on aspectRatio derived from metadata.

Note that this doesn’t mean setting up “auto” keywords for width and height. I agree that’s bad to expose externally.

If you’re willing to entertain the notion of an extra div, all of your use cases in the initial comment can be handled using intrinsic ratios. I can type up a full rundown if it’s helpful. I agree it’s painful from a markup perspective, but it seems possibly less painful than tracking down and patching every possible bug involving switching back and forth between broadly conceived fluid and fixed modes. That frankly sounds like a nightmare to write and maintain.

There is one tricky use case. I’ll call it “the stretch”:

videojs('id', { aspectRatio: '16:9’, width: ‘500px’; height: ‘500px’ })
// The author wants to stretch a widescreen video into a square.
// It doesn’t matter for this case whether aspectRatio is supplied, or comes from metadata.

This genuinely requires a “fixed” mode, because negative height or negative padding would be needed to compensate in certain cases, and those values aren’t allowed. While legitimate, this use case seems to be nicely isolated. Maybe add a “stretch” class when all three options are supplied and the math doesn't line up?

[heff]

Is stretch similar to background: cover and the BigVideo.js example? If so I don't think we need to try to fit that use case into this API, but still good to be aware of.

There might be an opportunity to avoid the second div and instead set the tech element to position:relative, and add the padding height to that, but as is that would create a flash of zero height when switching between techs (e.g. playing ads). And so far we've relied on everything being position:absolute in the player, so that would take some serious testing.

Defaulting to fluid is too big of a change and detraction from the spec to do before 5.0, and I'd like to get something in sooner, so I could see this going in two steps either way.

1. get aspect ratio support into the current model.
2. Consider defaulting to fluid and the best approach.

If there's potential for defaulting to fluid in the future, then aspectRatio might be the better option name than fluid. But in the first step we'd still be better off assuming that if the user uses aspectRatio that they want a fluid layout support. With that being the case, I think the user stories in the issue body hold up and we could start working on those.

[albell]

“Is stretch similar to background: cover and the BigVideo.js example?”

“Stretch” and “cover” are completely different use cases. Stretch shows all of the video, at a tweaked proportion. Kind of like when you resize an img in photoshop with the “constrain proportions” checkbox unchecked. You get the same thing in a browser for an img when you write:

<img src=“mypic.jpg” width=“1000” height=“500” style=“width:2000px”>

(The height will stay fixed at 500px, and not bump up to 1000px unless you add in height: auto!important.)

Cover (at least in <a href-“http://www.w3.org/TR/css3-background/#the-background-size”>CSS background-size) is when the image maintains its aspect ratio, but the image grows so that the container is completely covered by image. Part of the image is cropped, not shown, either at the top/bottom or at the sides, never both. The logic for this is actually fairly simple:

if aspectRatioVideo <= aspectRatioContainer {
    videoHeight = containerHeight;
    videoMarginLeft = -1 * ( videoWidth - containerWidth ) / 2;
} else {
    videoWidth = containerWidth;
    videoMarginTop = -1 * ( videoHeight - containerHeight ) / 2;
}

and set the container CSS to overflow:hidden.

“There might be an opportunity to avoid the second div and instead set the tech element to position:relative, and add the padding height to that."

That won’t work as you’ve described it. The intrinsic ratios padding-top solution and the “put the player in-flow” solution I argued for in #359 are different solutions. You can’t apply both simultaneously without pushing the container div height taller than the tech height, which is just wrong. Conceivably you could use padding-top to give the box height before the metadata has loaded, then turn off the padding, change the display of the tech to static to put it in-flow. But that sounds needlessly complicated.

” but as is that would create a flash of zero height when switching between techs (e.g. playing ads).”

Well, you could write it so that for consecutive videos, the previous video's padding-top stays in place until the next video's metadata loads, to avoid a FOZH™.

"Defaulting to fluid is too big of a change and detraction from the spec."

Well, as far as the spec, it’s actually closer to how the video element behaves. Also, I’m not suggesting defaulting to fluid per se, I’m suggesting defaulting to any fixed width supplied by the author, and if no width or height is supplied by the author, defaulting to the width (and thus also height) in metadata. That isn’t exactly fluid, it’s actually fixed, at least until author CSS (e.g. container max-width) gets involved. In my understanding, that is how the video element works. What I am suggesting is relying on padding-top to give the player height across the board, in all cases except stretch.

[ckarbass]

Just curious what the status is with this feature. Would be very useful.

[heff]

Just haven't had a chance to implement it yet. Feel free to try if you're interested.

[ernsheong]

A possible implementation (not by me): http://coolestguidesontheplanet.com/videodrome/videojs/

<video... width="auto" height="auto" ...>

.video-js {padding-top: 56.25%}
.vjs-fullscreen {padding-top: 0px}

[hsdk123]

+1 This would really be a great feature to have!

[andrewhood125]

I would love to see this happen.

[mmcc]

Still working on this one, but the implementation @ernsheong referenced is a great starting point for something looking for a stopgap solution.

[mmcc]

For anyone else that's implementing the workaround @ernsheong mentioned, you'll need to absolutely position the poster image in order to see it. It's currently set to fill 100% of the parent element, which doesn't work when using this workaround.

.vjs-poster {
  position: absolute;
  top: 0;
  bottom: 0;
  right: 0;
  left: 0;
}

[eeshan89]

+1

[xbgmsharp]

+1
To support Responsive Design, I used http://coolestguidesontheplanet.com/videodrome/videojs/

[mmcc]

Thanks for the feedback, everyone. This definitely something we're targeting to fix by 5.0 (at latest). I don't want to lock the issue because feedback on implementation would be fantastic, but no more +1s are needed at this point.

[jgubman]

We were able to factor in the height of the browser window by setting the width of an outer container using vh units (width: 124vh;). You can see a demo on our video player pages:
http://www.funnyordie.com/videos/18e820ec3f/between-two-ferns-with-zach-galifianakis-president-barack-obama

[cbt3]

I see that it works, but I am sorry I am kind of a novice with this sort of this and the source code of your site is completely overwhelming to me lol.
Even when I crtl+f I couldn't find anything referencing "vh" units

[jgubman]

vh is a viewport height unit, here are a few good overviews:

http://css-tricks.com/viewport-sized-typography/ http://css-tricks.com/viewport-sized-typography/

http://demosthenes.info/blog/660/Using-vw-and-vh-Measurements-In-Modern-Site-Design http://demosthenes.info/blog/660/Using-vw-and-vh-Measurements-In-Modern-Site-Design

On Sep 29, 2014, at 1:45 PM, cbt3 [email protected] wrote:

I see that it works, but I am sorry I am kind of a novice with this sort of this and the source code of your site is completely overwhelming to me lol.
Even when I crtl+f I couldn't find anything referencing "vh" units

—
Reply to this email directly or view it on GitHub #982 (comment).

[cbt3]

If I create "div { height: 50vh; } code, i end up with this
http://live-uat.plma.net/pre/test.png
The height will be responsive, but only by adding black and losing the locked aspec ratio of the video player (although the video itself remains 16x9)
This results in the video being cut off at the bottom and needing to scroll.

div { height: 50vh; }


.wrapper{padding:1% 1%;border:solid 2rem #fff;}

.videocontent{max-width:1280px;max-height:720px;margin:0 auto;}

.video-js{padding-top:56.25%;}.vjs-fullscreen{padding-top:0px;}

Reducing the value of the vh only reduces how much extra black is present.

If I try putting height: 50vh; in the .wrapper or .videocontent, nothing happens, also if i try doing it inline in the

still nothing happens

Like I said, I am pretty dumb with this stuff, thank you guys for trying to help.

[jgubman]

Don’t wrap a div w/ height: 50vh, instead keep the settings you already have in .videocontent and add a "width: 125vh;" declaration.

Also, if you need help w/ CSS, you should take the discussion to stackoverflow or somewhere. The github issues isn’t a very appropriate place to have this discussion.

On Sep 30, 2014, at 8:45 AM, cbt3 [email protected] wrote:

If I create "div { height: 50vh; } code, i end up with this
http://live-uat.plma.net/pre/test.png http://live-uat.plma.net/pre/test.png
The height will be responsive, but only by adding black and losing the locked aspec ratio of the video player (although the video itself remains 16x9)
This results in the video being cut off at the bottom and needing to scroll.

div { height: 50vh; }

.wrapper{padding:1% 1%;border:solid 2rem #fff;}

.videocontent{max-width:1280px;max-height:720px;margin:0 auto;}

.video-js{padding-top:56.25%;}.vjs-fullscreen{padding-top:0px;}

Reducing the value of the vh only reduces how much extra black is present.

If I try putting height: 50vh; in the .wrapper or .videocontent, nothing happens, also if i try doing it inline in the

still nothing happens
Like I said, I am pretty dumb with this stuff, thank you guys for trying to help.

—
Reply to this email directly or view it on GitHub #982 (comment).

[cbt3]

Sorry, I thought it was relevant to the responsive sizing discussion.
This works now for the height, which is great, but the width no longer is responsive.

[digitalmoksha]

I have tried using the CSS only solution mentioned by @j4k3 on Aug 2. In general, this worked well for me. However, the aspect ratio was somehow thrown off just enough to create extra "space" above/below the video. Could not figure out how to fix that.

The CSS solution is basically the same as outlined in the css-tricks article (as well as other places): Fluid Width Video. In there they put height: 0; in the wrapper, which in this case is the .video-js:after block. Adding this closed up the extra space.

.video-js {
    width: 100% !important;
    height: auto !important;
}
.video-js:after {
    content: '.';
    display: block;
    position: relative;
    padding: 40.1% 0 0 0; /* (height/width)*100%, eg. 56.25% for 16:9 75% for 4:3 */
    margin: 0 0 0 -100%;
    visibility: hidden;
    height: 0; 
}

Just posting in case someone else runs into this problem...

[ghost]

this is css u can use for responsive

body .video-js .vjs-tech {
position: static;
max-width: 100%;
height: auto;
}

[jbruni]

I would say that CSS transform is the best implementation choice. Ancient browsers are pre-mobile, and we usually want responsive for mobile environment. I would rather develop a good rock-solid solution using CSS transform, and offer a best-effort solution fallback for stone age browsers.

[anonym24]

.video-js-responsive-container.vjs-hd {
  padding-top: 56.25%;
}
.video-js-responsive-container.vjs-sd {
  padding-top: 75%;
}
.video-js-responsive-container {
  width: 100%;
  position: relative;
}
.video-js-responsive-container .video-js {
  height: 100% !important; 
  width: 100% !important;
  position: absolute;
  top: 0;
  left: 0;
}

hd = 16:9, sd=4:3

<div class="video-js-responsive-container vjs-hd">
    <video .... standard videojs code ... >
        ... sources ...
    </video>
</div>

http://stackoverflow.com/a/24413783 (Adapted from: http://css-tricks.com/NetMag/FluidWidthVideo/Article-FluidWidthVideo.php)

That css code works great: http://rmshow.tk/ (example video.js resizing)

[odev79]

Responsive Sizing

#982
@digitalmoksha commented on 14 Oct 2014

I have tried using the CSS only solution mentioned by @j4k3 on Aug 2. In general, this worked well for me. However, the aspect ratio was somehow thrown off just enough to create extra "space" above/below the video. Could not figure out how to fix that.

The CSS solution is basically the same as outlined in the css-tricks article (as well as other places): Fluid Width Video. In there they put height: 0; in the wrapper, which in this case is the .video-js:afterblock. Adding this closed up the extra space.

.video-js { width:100%!important; height: auto!important; }
.video-js:after { content:'.'; display:block; position:relative; padding:40.1% 0 0; margin:0 0 0 -100%; visibility:hidden; height:0; }

Example:

https://gist.github.com/odev79/6f30981e24123ad7df3c

[mmcc]

Closed thanks to #1952.

[SimonEast]

To save people from reading this enormous thread, can something be added to the README that explains how to implement fluid/responsive sizing?

[heff]

@SimonEast wanna help put one together?

[B1-0S]

If base video is 1903x965 ...
adding the same to jQuery(window).resize() makes it even responsiver :D

var windowWidth = $(window).innerWidth();
var sizeRatio = windowWidth/1903;
var videoHeight = 965*sizeRatio;
$(".videocontent").height(videoHeight);

[jgmio]

yes @SimonEast : I am missing some real documentation. There isn't a chapter on how to use data-setup properly and what options are available.

I love the performance of videojs but getting the videos to stay within the my containers is becoming a hassle

[gkatsev]

Not really documentation but I wrote a bit about fluid mode here: http://videojs.github.io/blog/Video-js-5-s-fluid-mode-and-playlist-picker/
I also plan on tackling docs soon.

[jgmio]

I tried another player but I'm going to give video.js another attempt. Hope I can get it playing nicely

[jgmio]

What am I missing? I feel like such a noob atm.

I'm including screenshots of the code and result between videojs with & without fluid.
But also one of JWplayer

The html

<div class="screen" >
     <video>
     </video>
 </div>

The css for ".screen"

width:24%;
margin:2px;

VideoJS { fluid :false }

VideoJS { fluid :true}

JWplayer

[nebrot]

Do you include css of video-js, for example http://vjs.zencdn.net/5.10.7/video-js.min.css ?

[jgmio]

I'm almost sad that I did include it ;)
Thanks for the suggestion.

[jgmio]

A friend came to the rescue. Hopefully I will have time soon to add it to your codebase as a setup option "responsive : true".

Init:

videojs(....).addClass("video-js");

css:

.video-js {
    height: 0px !important;
    width: 100% !important;
    padding-top: 62.5%; // or find aspect ratio of video, e.g. 16:9 and do calc(B/(A/100) = aspectRatio -> calc(9/(16/100) = 56.25%
}

[gkatsev]

you probably also want to call player.aspectRatio with 16:9 or something like that or add the vjs-16-9 class to the player.