Browser locks on player load while parsing all VTT files

[ksheurs]

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?

[ksheurs]

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.

[mmcc]

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?

[ksheurs]

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

[ksheurs]

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.

[mmcc]

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]

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.

[gkatsev]

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]

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.

[ksheurs]

@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]

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]

@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!

[gkatsev]

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]

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 mozilla/vtt.js#340

[heff]

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

[gkatsev]

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

[altaywtf]

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.

[davegonzalez]

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).

[gkatsev]

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.

[ryanische]

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.

[gkatsev]

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.

[ryanische]

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.

[gkatsev]

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.

[Fabiencdp]

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

[ryanische]

@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.

[mhdSid]

@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

[altaywtf]

@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.

[gkatsev]

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.

[fehmi]

onst tracks = this.tech_.textTracks();

Where can I find this file? I want to delete this lines and try.