Video.js: Browser locks on player load while parsing all VTT files

Created on 28 Feb 2015 · 28Comments · Source: videojs/video.js

I'm finding on videos that have ~10 subtitles (various different languages) the entire browser locks while VideoJS goes through and parses all of them. I can see users trying to click the play button and thinking the player is broken with no immediate playback/feedback.

Is it necessary to parse all these on load vs 1x1 as the user selects a particular language? If not, is there any way to do this in a non blocking fashion?

We are using VideoJS on a premium video service. I can't see putting this into production as is. If this is the way it will behave for foreseeable future, is the only other option video.novtt.js?

bug confirmed pinned

Source

ksheurs

Most helpful comment

Just spent some time looking at this again. It's been a while.
First thing, in Video.js 7.7 we finally have an option to not preload all the text tracks and only load them on demand. You can set it like so:

{
  "html5": {
    "preloadTextTracks": false
  }
}

Please try it out and report back.

I'll also take a look at making the parser async based on existing work but there's no timeline for this. Hopefully, the preloadTextTracks: false is good enough for most usecases.

gkatsev on 27 Nov 2019

👍3

All 28 comments

I'm finding this pre-fetching of all tracks + browser locking only happens on the Flash tech FYI. HTML5 lazy loads them per selection.

There is about ~10 seconds of no interaction ability with the player. I also get a few VIDEOJS: ERROR: ParsingError on Flash tech, but not HTML5. After all have loaded, I am able to play the video and all tracks work.

ksheurs on 1 Mar 2015

Do you have an example player that you can point us to so we can take a look? I assume so, but are you seeing this with _any_ browser loading the Flash tech?

mmcc on 2 Mar 2015

Getting a demo together now @mmcc. Will report back soon. Thank you!

ksheurs on 3 Mar 2015

Hi @mmcc. I've put together a reduced test case here: http://jsbin.com/semitutufo/1/. These are tracks for a different (feature length) film, but it demonstrates the bug.

You can see in Chrome (HTML5 tech) the player is responsive and tracks are loaded as needed.

In Firefox (Flash tech) the browser almost crashes as it tries to load and parse all the tracks on load.

I do not recall this happening pre VTT.js integration.

ksheurs on 9 Mar 2015

Doesn't look like this is a Flash tech issue, seems to be a browser issue. Firefox doesn't need the Flash tech to play the MP4 source, but I'm still seeing the player go unresponsive for a moment.

mmcc on 9 Mar 2015

By the way, thanks for the reduced test case, @ksheurs. Don't really have much else to say yet, but at least it's useful to know that this doesn't seem to be tech specific.

mmcc on 9 Mar 2015

It sounds like this issue has to do with the emulated text tracks which always run in Firefox right now because of a known issue.
Even though we're making the XHRs for downloading all the files asynchronously, it might be that they all come back at once. There's probably some work that needs to happen to figure out specifically why the slow down happens since everything is done asynchronously, so, the browser should have time to get in between each request coming back.
20 tracks is a lot but we should be able to handle it.

gkatsev on 9 Mar 2015

Also, I noticed that your files are not to spec which might make it worse. Since we switched to vttjs, our parsing is much more strict.

gkatsev on 9 Mar 2015

@mmcc @gkatsev thanks. i may not be clear on the issue, but here is the same demo, but forcing flash: http://jsbin.com/hewamuwali/1/. see in chrome the browser locks up as well. so it's not just a firefox/browser issue?

i think whether a more modern firefox browser can handle native vtt or not, we still may have an issue in older browsers or as it seems, anytime flash is being used for playback?

ksheurs on 10 Mar 2015

Hey guys, any findings on this? Curious why the emulated text tracks (pre-fetching / parsing of all tracks) is happening in Chrome if using the Flash tech.

Does Flash require all the tracks be loaded first? If not, maybe we can just defer the emulated track parsing on selection of subtitle language, instead of videojs init.

ksheurs on 12 Mar 2015

@mmcc @gkatsev any ideas? we'd love to roll out the new videojs version, but this is holding us up. it seems that any flash experience causes this browser locking (please see updated demo above). we distribute movies, so often there are 10+ tracks. thank you again!

ksheurs on 16 Mar 2015

I have a proposed fixed in #2192 which will loaded tracks on demand. Default tracks will still be downloaded on player init, but you really should only have one default track.

gkatsev on 22 May 2015

So, looks like the main culprit here is vttjs's parsing of the files. Loading in the text tracks asynchronously/on demand will only mitigate the issues. See https://github.com/mozilla/vtt.js/issues/340

gkatsev on 2 Jun 2015

Bummer. How much effort would it be to put together a vttjs PR just for the try/catch wrapping change?

heff on 3 Jun 2015

Just wrapping the try/catch isn't significant enough of a change to warrant doing it by itself.

gkatsev on 3 Jun 2015

this is very drastic especially on gaming devices like ps4 and xbox.

"{"name":"ParsingError","code":1,"message":"Malformed timestamp: 00:02:53,040 --> 00:02:54,359"}"

when my player has errors like above, it causes playstation to freeze then throw there is not enough free system memory error.

are there any workarounds for this? can we detect is subtitle malformed before adding it to the player?

update: we've fixed malformed timestamp issue but player still freezes when I hit the play button.

altayaydemir on 20 Apr 2017

Has there been any movement on this? Any workarounds? I'm trying to upgrade our player from 5.12 to 6.20 but am running into this (also ran into this with 5.20.4).

davegonzalez on 24 Oct 2017

Unfortunately, we haven't had the time to work on this. It potentially requires a large refactor of the vtt.js project or potentially move vttjs to a webworker which also isn't a small amount of work.

gkatsev on 24 Oct 2017

I am experiencing this issue with a ~30 minute video with 17 caption <track> elements. From profiling with Chrome's performance tool it looks like much of the time is spent in removeCue in TextTrack. The specific call stack is oncue -> addCue -> removeCue.

I noticed that addCue does the following:

    const tracks = this.tech_.textTracks();

    if (tracks) {
      for (let i = 0; i < tracks.length; i++) {
        if (tracks[i] !== this) {
          tracks[i].removeCue(cue);
        }
      }
    }

removeCue then iterates through all the cues in the text track looking for a match and removing the cue if found. From digging around a bit, this seems to be because browsers might have already added cues for a given text track (not highly confident this is the reason - any clarification would be welcome). I did notice that for my video with its 17 text tracks that the cue match condition in removeCue is never met. The end result is that a lot of work is done for no benefit (as far as I can tell).

What is the purpose of iterating through all the text tracks and their cues looking for a match in addCue? Is this something that could be avoided when the text tracks are being loaded vtt.js? I'm assuming there are use cases for addCue outside of parsing the source of a caption/subtitle <track> that necessitate the need for looking for a duplicate cue.

ryanische on 20 Feb 2018

👍1

That seems to be a separate issue from this one @ryanische, though, still related. The main issue here is that the actual parsing of the files takes a long time (1s at least) and it's blocking. So, if you have a bunch of large files, you could end up waiting for a long time before the page becomes responsive again.

Spending a lot of time in removeCue seems a separate issue. However, the reason for that is because a particular cue can only be in one specific track. It's possible that what we want to do is during parsing disable the removeCue call and re-enable it afterward. However, I think that's best tracked in a separate issue.

gkatsev on 20 Feb 2018

thanks @gkatsev - would you like me to open another issue?

As for disabling removeCue during parsing - that's what I had in mind - adding an argument (with a default) that could be set to false in the oncue handler.

ryanische on 20 Feb 2018

A new issue would be great. Main concern with adding an argument for this is that users of Video.js could potentially call addCue and disable the removeCue check.

gkatsev on 20 Feb 2018

@ryanische, I'm interested too, did you still want to open a new issue or can i ?

Fabiencdp on 2 Mar 2018

@Fabiencdp I'm working on getting an example setup so I can link to that in a new issue. Hoping to have it up today or Monday.

ryanische on 2 Mar 2018

@altayaydemir I would like to ask how were you able to play videos on PS4? what was the mime type that you used? m3u8 or mpd?
Could you please guide me through this because I'm not able to play m3u8 nor mpd on PS4.
Video.js throws invalid source type

mhdSid on 29 Aug 2018

@mhdSid they were mp4 files. I think the struggle occurs while trying to parse subtitle files for long videos, especially if they have malformed timestamps. I tried to calm it down by loading one subtitle at a time instead of many but it didn't help as much as I expected. in order to resolve this, we detect PS4 by looking the user agent and load jwplayer (with flash as the primary choice) in that case and it's performing better.

altayaydemir on 29 Aug 2018

{
  "html5": {
    "preloadTextTracks": false
  }
}

Please try it out and report back.

I'll also take a look at making the parser async based on existing work but there's no timeline for this. Hopefully, the preloadTextTracks: false is good enough for most usecases.

gkatsev on 27 Nov 2019

👍3