VP-75: Selecting a cue in the transcript results in the video being placed at the previous cue

Description

When you select a cue in the transcript pane, the video gets positioned at the cue before the one you've selected.

Comments

• Alexey Novak commented 2012-09-20T10:46:55.291-0400

  Looks like console always gives an error for
  var lastBufferedTime = that.model.buffered.end(that.model.buffered.length - 1);

  which is in VideoPlayer_controller.js on line 319

  This problem is irrelevant for the current problem. Even when there is no error on this line, the issue is still persists. A separate JIRA should be opened for the observed behaviour above.

• Alexey Novak commented 2012-09-20T11:30:24.447-0400

  If you click on the "catch a tiger by the toe" transcript with a breakpoint in captionator.js at line 1203
  you will see that the currentTime propagated is 4.003 and then if you look at the .srt file the interval for this caption is
  2
  00:00:04.03 --> 00:00:05.99
  Catch a tiger by the toe

  which means that time does not fall into this interval

• Alexey Novak commented 2012-09-20T11:45:56.921-0400

  The issue is this line
  return Math.round(secs * 1000 + parseInt(splitSec[1], 10));

  in VideoPlayer_transcript on line 144

  If the time is 04.03 which means 4030 ms
  The formula would do 4 * 1000 + 3 = 4003ms

• Alexey Novak commented 2012-09-20T12:20:52.009-0400

  Got tests and the issue with unproper time conversion fixed but issue still persists.

• Alexey Novak commented 2012-09-20T13:45:53.151-0400

  With the function fix and changing line 181
  that.events.onTranscriptElementChange.fire((1 + inTimeMillis) / 1000, track);
  to be
  that.events.onTranscriptElementChange.fire((10 + inTimeMillis) / 1000, track);

  The bug seems to be fixed with the change but it would be better to find the exact location to be 100% sure. Most likely it is because of the format of type HH:MM:SS.mmm which happens after adding this 1 extra millisecond while code seems to work when format used by VideoPlayer stays the same as the format used by captionator which is HH:MM:SS.mm

• Alexey Novak commented 2012-09-21T10:09:11.281-0400

  After more thorough research I finally found that the times which are pulled from UniSub and times which are in our en.json transcript files do not match.
  In particular UniSub has a time precision up to a millisecond while we have only up to 10 milliseconds. Hence the line described in above comment would not do much.

  Examples:
  Our time 00:00:04.03 and after adding 1 millisecond it would become 00:00:04.031
  While the time range returned from UniSub is
  "inTime": "00:00:04.033",
  "outTime": "00:00:05.992",
  which means that the match will fall into the previous caption.

  Furthermore some times were radically different. Example:
  We have in our transcript file
  "inTime": "00:01:00.00",
  "outTime": "00:01:03.18",
  "transcript": "we try to find commonality and connections."

  Captions returned from UniSub
  "inTime": "00:01:00.864",
  "outTime": "00:01:03.185",
  "transcript": "try to find commonality and connections."

  The difference is 0.864 milliseconds.

• Colin Clark commented 2012-09-25T11:33:03.281-0400

  The solution in Alex's latest pull request for this issue--simply updating our demo files to include timestamps with three digits of accuracy--is the correct one. I have reviewed, tested and pushed this fix to the project demo branch at db320a36e4386d129f46513eec94563d230e0231.