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

UITextDisplayer.append or Cue.equal is very slow, especially on Chromecasts #3018

Closed
baseballbrad3 opened this issue Nov 30, 2020 · 1 comment
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@baseballbrad3
Copy link
Contributor

Have you read the FAQ and checked for duplicate open issues?
Yes

What version of Shaka Player are you using?
3.0.5 and 3.0.6

Can you reproduce the issue with our latest release version?
Yes

Can you reproduce the issue with the latest code from master?
Yes

Are you using the demo app or your own custom app?
Custom app

If custom app, can you reproduce the issue using our demo app?
Yes

What browser and OS are you using?
Cast Sender: Chrome 87/Windows 10
Cast Receiver: Chrome 76/Chromecast Ultra

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
Chromecast Ultra 1.42.183786 (User agent: Mozilla/5.0 (X11; Linux aarch64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.81 Safari/537.36 CrKey/1.42.183786)

What are the manifest and license server URIs?

I might be able to provide this via email, but if you have a title with lots of text track cue's (1,000+), I'd expect that to work the same.

What did you do?

  1. Prior to casting, in the sender's Shaka player instance, select a text track. Alternatively, configure the Shaka player on the Cast receiver's configuration to streaming.alwaysStreamText to true.
  2. Start the Cast session on a Chromecast (I'm using a Chromecast Ultra)
  3. Wait between 30 seconds and 1 minute for playback to begin

Note that the longer the content (or one with more dialog), the worse this start up time seems to be. I'm testing on an action movie that has 1275 lines of dialog (basically I mean it's a VTT with 1275 --> occurrences).

What did you expect to happen?
The video to begin without waiting over 30+ seconds for the text track to parse.

What actually happened?

Basically any loading of text tracks on a Chromecast (weather it's selected prior to casting, changed while casting, or having streaming.alwaysStreamText to true) takes an unreasonably long time on text tracks of a movie length.

I'd assume this would impact non-Cast devices too. Running a performance profile on the debug Shaka demo site for the same content on my Chrome (a desktop Core i7, not the Cast Receiver) took ~600ms. 😬 An underpowered/older Android phone could take seconds (perhaps tens of seconds), but I don't have evidence of this.

Here's a screenshot of the performance tab of the receiver's inspect window after I switched text tracks. I did save Chrome's performance profile, if it's needed.
chrome_2020-11-30_12-20-24

It looks like this this was introduced in 3.0.5 with the changes made to cue.js and array_utils.js.

@bcupac
Copy link
Contributor

bcupac commented Dec 1, 2020

the append function looks like this:

for (const cue of cues) {
      // When a VTT cue spans a segment boundary, the cue will be duplicated
      // into two segments.
      // To avoid displaying duplicate cues, if the current cue list already
      // contains the cue, skip it.
      const containsCue = this.cues_.some(
          (cueInList) => shaka.text.Cue.equal(cueInList, cue));
      if (!containsCue) {
        this.cues_.push(cue);
      }
    }
 this.updateCaptions_();

If external cc is loaded, and has 1000+ cues, shaka.text.Cue.equal will trigger millions of times.

One idea to solve this is to hash cues based on start/end times and then just compare those hashed values between each other. About 99% of
hashes will contain just a single cue point, so the compare function will not trigger.

append(cues = []) {
		const hashedCues = new Map();

		// when using external Captions append is called only once, but when Captions are in the manifest
		// append is called multiple times as playback progresses and this.cues_ is filled in gradually.
		const mergedCues = [...this.cues_, ...cues];
		const normalizedCues = [];
		// When a VTT cue spans a segment boundary, the cue will be duplicated
		// into two segments.
		// To avoid displaying duplicate cues, we remove duplicate cues below.
		// from observation duplicates are most often found in manifest embedded captions.
		mergedCues.forEach(cue => {
			const alreadyHashedCues = hashedCues.get(`${cue.startTime}+${cue.endTime}`);
			if (!alreadyHashedCues) {
				hashedCues.set(`${cue.startTime}+${cue.endTime}`, [cue]);
			} else {
				hashedCues.set(`${cue.startTime}+${cue.endTime}`, [...alreadyHashedCues, cue]);
			}
		});

		hashedCues.forEach(c => {
			const tempComparisonCues = [];

			c.forEach(cue => {
				const containsCue = tempComparisonCues.some(tempCue => shaka.text.Cue.equal(tempCue, cue));
				if (!containsCue) {
					tempComparisonCues.push(cue);
					normalizedCues.push(cue);
				}
			});
		});
		this.cues_ = normalizedCues;
		this.updateCaptions_();
	}

@joeyparrish joeyparrish added type: bug Something isn't working correctly and removed needs triage labels Dec 21, 2020
@shaka-bot shaka-bot added this to the v3.1 milestone Dec 21, 2020
joeyparrish pushed a commit that referenced this issue Dec 23, 2020
When a VTT cue spans a segment boundary, the cue will be duplicated
across two segments.
To avoid displaying duplicate cues, we compare the cues to be
appended with the cues already in the list.

1. We can assume the cues to be appended at once have no duplicates.
Make a copy of the current cues list, and compare the new cues only
with the cues in the current cues list.
If we append m new cues to a list of n cues, we can reduce the times to
compare the cues from m*m*n/2 times to m*n times.

2. We compare the cues deeply by comparing their nested cues and
all the elements. We can compare their start time, end time and payload
first, and only compare their nested cues and all other elements when
their start time, end time and payload are the same.
If cue1 and cue2 both have m nested cues, we may not need
to compare the nested cues instead of comparing m times.

Fixes #3018

Backported to v3.0.x

Change-Id: I9992f0e1834fd16e8aedaf1895b036bc7ca29190
joeyparrish pushed a commit that referenced this issue Jan 6, 2021
When a VTT cue spans a segment boundary, the cue will be duplicated
across two segments.
To avoid displaying duplicate cues, we compare the cues to be
appended with the cues already in the list.

1. We can assume the cues to be appended at once have no duplicates.
Make a copy of the current cues list, and compare the new cues only
with the cues in the current cues list.
If we append m new cues to a list of n cues, we can reduce the times to
compare the cues from m*m*n/2 times to m*n times.

2. We compare the cues deeply by comparing their nested cues and
all the elements. We can compare their start time, end time and payload
first, and only compare their nested cues and all other elements when
their start time, end time and payload are the same.
If cue1 and cue2 both have m nested cues, we may not need
to compare the nested cues instead of comparing m times.

Fixes #3018

Backported to v2.5.x

Change-Id: I9992f0e1834fd16e8aedaf1895b036bc7ca29190
@shaka-project shaka-project locked and limited conversation to collaborators Feb 19, 2021
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

5 participants