fix: VTTCues with identical time intervals being incorrectly removed

[alex-barstow]

Description

This is a replacement for #995, which was an attempt to revert a PR that resulted in WebVTT cues with identical time-intervals (which the spec allows) being removed from the cue list. However, simply reverting the change broke 608 captions, so another solution was required.

The main goals of this PR are to:

1. Make sure WebVTT cues are not removed from the TextTrackList just because they have the same time-intervals
2. Satisfy the original purpose of this logic (originally this) that I removed, which is to make sure any cues that "overlap" VTT segments (cues that are both the last cue of one segment and the first cue of the next segment) are removed.

Solution

We can meet those criteria by only removing cues that have identical time intervals and identical text. This will ensure we remove any cues that overlap VTT segments, while keeping any cues that are actually intended to be displayed at the same time (which we can reasonably assume will have different text)

Specific Additions

1. Create removeDuplicateCuesFromTrack() function in text-track utils
2. Modify the vtt-segment-loader so that we run the de-duping after adding VTTcues from a new segment
3. Unit tests

[gkatsev]

Just tested 608 and the stream that promted this and looking good.

[gkatsev]

Should this happen after both forloops? It'll make it less likely that the loop fails because the cues list got updated from under it.

[alex-barstow]

Following some offline discussion, we've decided to leave this as is. The loop will start with the first cue, remove any duplicates of it, progress to the second cue, remove any dupes of that, etc. And the length of the cues array is updated accordingly as duplicates are removed, so this should be safe.

[brandonocasey]

The logic is way better here 👍 👍

[robflynn]

@gkatsev @alex-barstow

I submitted the bug report that I believe led to this PR.

In reviewing the code ran across a possible additional issue that wan't covered in the fix regarding simultaneous captions.

In the code you mention that you're dropping captions if their time codes and text match.

You might want to also consider cue position in this check as duplicate text is not always safe to purge. I have seen multiple examples in the past of simultaneous captions WITH the same text, but on opposite ends of the screen. (Think two people surprised and shouting: "Dude!?" from opposite ends of the screen.)

[gkatsev]

Thanks @robflynn that definitely makes sense. Really, I think that our deduping should be limited to our 608 captions but I think it's not easy for us to differentiate where we do the deduping right now.