Fix captions overlap with transcript cue clicks

[Dananji]

Related issue: #946

When there are adjacent transcript cues that share an end time and a start time (a common boundary), both cues get highlighted and and displayed in the VideoJS player when seeking. Adding a 1ms offset to the playback time when synchronizing the transcript component with the VideoJS player fixes this.

The screen recording shows the transcript cue highlighting and VideoJS caption display updates when player is paused for the following 3 cues in its transcript,

37
00:01:20.000 --> 00:01:24.000
LANDSCAPE,DERSTAND

38
00:01:24.000 --> 00:01:28.000
THE HOUSES HE DESIGNED.
WE ARE ALSO USING IT AS THE

39
00:01:28.000 --> 00:01:31.000
LIVES OF ENSLAVED PEOPLE.

shared-boundary-cue-highlights.mov

[cjcolvar]

This is a clever workaround.

Does this cause any problems with the beginning or end of the stream?
I want to make sure we don't introduce an off by 1 issue since seeking won't be to exactly 0 and seeking to the end will be just past the end. Alternatively you could probably add those two base cases here that makes 0 be 0 and the end be the end. Thoughts?

[Dananji]

Thank you for pointing that out! It's a very valid point that I hadn't fully considered :)

The new offset would indeed be an issue for a cue with a duration less than 1ms. For instance, a cue with a 1ms duration -- such as { start: '00:00:00.000', end: '00:00:00.001' } would be resolved to seek(0.001) using the start time with this adjustment. This would still keep the player's current time within the cue's boundaries.

As you noted, this offset might cause the player to jump to the next cue instead of displaying the current cue, but only for cues with a duration < 1ms. According to the VTT spec, a VTT timestamp has a precision of thousandths of a second (1ms). I also tested a sample VTT in the W3C VTT validator which flagged this issue in the timestamps.

Because of this, if such a cue were to exist in a given VTT file, it would likely be considered an invalid cue, which VideoJS would ignore regardless of this offset. Therefore, it seems unlikely to introduce a regression in practice.
So, introducing the two base cases might add a bit of complexity for a scenario that may not occur in the real-word usage, as cues shorter than 1ms are considered invalid.

Let me know what you think!