Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load text tracks on demand. #2192

Closed
wants to merge 4 commits into from
Closed

Conversation

gkatsev
Copy link
Member

@gkatsev gkatsev commented May 22, 2015

This PR is also a place for discussion around how we want to handle tracks.
Currently, I've changed it so that tracks get loaded on demand, i.e., when you select them to display, and not all at once when the player is loaded. default tracks get loaded on player creation, still.
The menu should still be showing up because the TextTrack object is being created, just that the cues aren't being populated.
Also, this might be causing issues with chapters as it is right now, but could be fixed by loading those initially along with the default tracks.

This fixex #1913 and related issues.

@dmlap @heff

@heff
Copy link
Member

heff commented May 22, 2015

Not to dig into unrelated things, but does this line do something?

this['activeCues'];

@gkatsev
Copy link
Member Author

gkatsev commented May 22, 2015

It does. It causes the activeCues getter to trigger which swaps out the cues in and out of the activeCues array

if (mode !== 'disabled' && this['cues'].length === 0) {
loadTrack(this.src_, this);
}

if (mode === 'showing') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should include hidden tracks too so cuechange events fire for those also. Would that mess anything up?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should.

@heff
Copy link
Member

heff commented May 22, 2015

Looks good to me. What are the open questions around how we want to handle tracks?

@gkatsev
Copy link
Member Author

gkatsev commented May 22, 2015

Specifically, this is a change in functionality. Previously, all tracks and their cues were available after load and now they won't be available until they're selected. Possibly, we want to be able to load all the tracks sequentially starting with the default tracks (and the selected tracks) rather than only loading tracks on-demand.
Also, as I mentioned, chapters should be verified before pulling this in.

@heff
Copy link
Member

heff commented May 22, 2015

Ok, so it ads an asynchronous step for each track as opposed to all up front. Do we know how the video element handles this by default?

@gkatsev
Copy link
Member Author

gkatsev commented May 22, 2015

I think it does load them all up as soon as possible, though, haven't tried it yet.

@gkatsev
Copy link
Member Author

gkatsev commented May 22, 2015

Actually, looks like chrome doesn't have any of the cues available until the track is shown and chrome only uses either the "best match", top/first, or the default track. So, actually, this won't be too dissimilar.

@heff
Copy link
Member

heff commented May 23, 2015

Nice. That's good. In Chrome are the cues available synchronously after showing a track?

@gkatsev
Copy link
Member Author

gkatsev commented May 23, 2015

Doesn't seem to be the case in chrome. Btw, here's a test page modified from #1913: http://output.jsbin.com/rubacujite/1/edit?html,output

This means that chapters, metadata, and descriptions will get loaded by
default on init instead of on demand.
@gkatsev
Copy link
Member Author

gkatsev commented Jun 1, 2015

Ugh, this has turned into a much worse thing to fix than I thought :)
With the files from #1913 loading in more than one item on init causes the video player to more or less lock up. So, we should need to add some event to know when a particular track has finished and loop through the items. Basically, #1949.
I'll look into merging the two PRs. I'll probably make a new PR for it.

@gkatsev
Copy link
Member Author

gkatsev commented Jun 3, 2015

I'm going to put this one on ice for a bit. The main issue with the really large text tracks from #1913 is that vttjs takes too long to parse (mozilla/vtt.js#340). Hopefully, I'll have some time later to look into that but don't have it immediately.

@gkatsev
Copy link
Member Author

gkatsev commented Jul 15, 2015

Going to close this PR. We can revisit it after the vttjs issue has been fixed.

@gkatsev gkatsev closed this Jul 15, 2015
@gkatsev gkatsev deleted the tracks-lock-up branch March 8, 2016 20:39
@bvibber bvibber mentioned this pull request Jun 11, 2019
7 tasks
bvibber added a commit to bvibber/video.js that referenced this pull request Nov 4, 2019
Reimplementation of videojs#2192
on current code. Seems to work but has not been carefully tested,
especially on conditions such as slow networks and complex tracks.

For videojs#5252

A `preloadTextTracks` tech option is added, set to true by default,
to keep current behavior intact. Alternate behavior can be enabled
by setting this to false.

This delays loading of the VTT cue files until they are selected.
For sites like Wikipedia that tend to have large numbers of
crowdsourced subtitles and can show many files together on one
page, this saves a lot of unnecessary network transfer and API
hits.

Does mean there may be dropped cues while switching to a track
that requires on-demand loading.

Example usage:

videojs(element, {
  html5: {
    preloadTextTracks: false
  }
};
gkatsev pushed a commit that referenced this pull request Nov 4, 2019
Reimplementation of #2192
on current code. Seems to work but has not been carefully tested,
especially on conditions such as slow networks and complex tracks.

For #5252

A `preloadTextTracks` tech option is added, set to true by default,
to keep current behavior intact. Alternate behavior can be enabled
by setting this to false.

This delays loading of the VTT cue files until they are selected.
For sites like Wikipedia that tend to have large numbers of
crowdsourced subtitles and can show many files together on one
page, this saves a lot of unnecessary network transfer and API
hits.

Does mean there may be dropped cues while switching to a track
that requires on-demand loading.

Example usage:

videojs(element, {
  html5: {
    preloadTextTracks: false
  }
};
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants