Video.js: How to load in vtt.js

[gkatsev]

In #1749 @heff brought up concern over how vtt.js should get included into the project.
The way it is currently set up is that it will try to load a node_modules folder or via a configured URL at run time. Probably the easiest way to make this work is to configure vjs to use a CDN version of our vttjs build. But we could also attach vttjs to the main vjs build but we'd still want to have our build of vttjs on the CDN for users to use.

Options:

• host vtt.js on the CDN. Default to that location on the player.
• prebuild vtt.js into videojs. Don't host on CDN, don't allow overriding of url.
• make several builds of videojs. Default builds include vtt.js, other builds don't include vtt.js. We probably should have a version of just vtt.js on the CDN for this well.

@heff @mmcc @dmlap

[heff]

My preference at this point would be to just bundle it with Video.js. (option 2)

• It's replacing an existing feature that people use today
• Separating out vtt.js means you have to define the location when self hosting video.js. I wish we didn't have to do that with the swf today, so I don't love the idea of adding more scripts like that.
• Lazy loading it would introduce asynchronicity that we have to handle

If file size becomes an issue we can work on a custom build process where you can exclude vtt.js. But I'd wait until people ask for that as it's not a massive addition.

[mmcc]

I agree with @heff on this one, option 2 makes the most immediate sense. I'm leaning towards more of a preemptive approach on the custom builds stuff rather than waiting for it to become an issue, but I don't think there's any major rush.

[dmlap]

It's 30k minified which means including it would be a 30% size increase for video.js. Normally, I would agree with the "simpler-is-better" option 2 approach but I don't know if <track> usage (by viewers) is widespread enough to warrant it. I prefer option 1.

[heff]

Have we done the major things we can to get the vtt.js file size down? I remember there was a big RTL character list and string encoding lib, that could both be optimized or potentially excluded.

Track usage may not be used by everyone but it's supported by the video element by default, which has been the line for whether or not features go into core. I was originally concerned with the size also, but if vtt.js (with all its size) is what we've determined is needed to appropriately support what the spec defines, then I say "so be it".

I also put as much weight on ease-of-use for the general video.js user as I do performance, so I wouldn't want to block the high-performance use case. What if we bundled vtt.js in the main download and CDN, but made it possible to exclude it with a custom build and load it later if needed?

[gkatsev]

Yeah, the RTL list is a pretty big optimization that hasn't been done.

Also, your last suggestion is option 3 :)

[heff]

Why yes it is. :)

[gkatsev]

So, do we want to go with option 3 then? If so, what file names do we want for the vtt.js-less builds? We should keep current file names as the builds with vtt.js.

[heff]

I was more thinking it would just be an option in the grunt build process.

[gkatsev]

Do we want to make users who would rather make a second request for vtt.js make their own build?
Maybe, we output this file to the dist and have it available in the npm package but not necessarily publish that to the vjs CDN?

[heff]

I'd rather not add it to the dist by default if we can avoid it. It adds complication around which version someone should choose to use, and if we make other portions of the codebase optional the dist would get out of hand.

If you're using browserify/npm to pull in video.js, does the dist even matter? Is there something we could be doing to make vtt.js optional in that process instead of doing a grunt custom build process?

Also, when we say that VTT.js can be optional, does that only include the VTT format parsing, or does that include all the track shims also? I'm thinking we should try to avoid an inconsistent landscape for plugin authors around whether or not a player supports tracks for timed events.

[gkatsev]

Browserify users might not need it, but it's possible they could want to use the pre-built option to save time in their own build.

The issue isn't necessarily to make vttjs optional, but rather to allow it to be loaded later on, so, it's not part of the initial request.

[gkatsev]

I just realized an issue with always loading in vttjs as opposed to only doing so when necessary. Currently, our build of vttjs is set up to _always_ override the global VTTCue. This is an issue because native text tracks will not let us add custom VTTCue objects into native text tracks.
VTTCue is always exported currently because native VTTCue in some browsers, chrome particularly, have some bugs with regard to placement.

[gkatsev]

Also, loading in vttjs asynchronously means that users who can use native captions, don't take the hit of the larger file size.

[heff]

Currently, our build of vttjs is set up to always override the global VTTCue

If it's the global VTTCue, then that's going to be a problem if there's two players in the page, one using custom and one using native captions. One player's captions shouldn't break another's, so I think that's a problem that needs to be fixed with vttjs, or at least our use of it. Can we turn off the exporting everywhere and just accept the chrome bugs for until they fix them?

[gkatsev]

Yeah, vttjs needs to be updated to allow us to use it as a self-inclusive package. That isn't something that can be fixed quickly.

[heff]

Can we detail what needs to happen? I don't want this to get blocked.

[gkatsev]

Make a build of vttjs that allows us to require it locally or on a named-spaced object.

[heff]

What are the part of vtt.js that need to be changed to make that happen?

Kind of hacky but could we wrap vtt.js in a function and pass in our own mock window object, then grab the exported vars from that?

[gkatsev]

vtt.js is build up of three files (that we care about) that take in a root object which is currently window.
I have at least today to fully look at captions, so, I'll take a look at how much work it'll take to modularize vttjs.

[heff]

Cool. In browsers that don't have VTT support, I think we still want the custom window.VTTCue to be available, so users can use track.addCue(). At least some how. While modularity is good either way, could we fix this issue for us by adding an option to vtt.js to not override window.VTTCue if already available?

[gkatsev]

Oops, didn't mean to close this.

vtt.js was previously only exporting their VTTCue if the native one didn't exist but yeah, it's possible that it just needs an option. The reason why I changed it is because in chrome, with emulated captions, the positioning of the captions is incorrect.

[gkatsev]

By modularize I meant just have it namespaced in some way that it's available but doesn't always clobber global namespace.

[heff]

Cool. Is there a Chrome bug we can track for that issue?

[gkatsev]

The issue only occurred with vttjs rendering using native VTTCues.

[gkatsev]

Might be easy to add a noConflict method or something.

[gkatsev]

This has been solved and implemented in the captions branch (#1749).

[gkatsev]

This is part of #1655 (pinging so we get a nice "closed" badge there).

[mhawk0]

@gkatsev will version 4.12.x "novtt version" be fixed so that it does not try to load "../node_modules/vtt.js/dist/vtt.js" when video.js is initializing, regardless captions added to video tag or not?

[markopavlovic]

:+1: for this above