Weird skipping during playback

[jbenet]

Sometimes during playback, the video skips.

Only observed so far in spliced videos. Unclear whether it happens in regular videos too.

see example

[jbenet]

I think this has something to do with it:

  _onProgressBarDidProgress: (percentProgress) =>
    progress = @progressFromPercent percentProgress

    # if slider progress differs from player progress, seek to new position
    unless progress.toFixed(5) == @seekOffset().toFixed(5)
      @seek progress

[tenedor]

@jbenet the example you posted is a private, inaccessible youtube video.

What do you expect is happening because of that code?

[jbenet]

@tenedor fixed video private -> unlisted

[jbenet]

That sometimes youtube seek offset advances at before it gets compared, so that when the comparison in _onProgressBarDidProgress happens, the times are not exactly in sync, even though playback is fine.

the video skips back, so progress must be less than @seekOffset()

[tenedor]

This a) shouldn't happen and if it did b) shouldn't cause the problem you're seeing.

a) This shouldn't happen because, when a user hasn't sought to a new location, the progress bar only updates to keep pace with the youtube video. This update and the event it throws, which triggers the method you posted, is a minimal amount of code to run, and would happen long before the youtube video progressed to a new time. This assumes the youtube player progresses at regular intervals - if it progressed multiple intervals at once, this might cause a bug.

b) This shouldn't cause the problem you're seeing, because the undesired seek would seek to the last offset that was registered correctly, likely only one frame earlier than the one playing. In the video you show, the seek is to some different part of the video, not simply to 0.1 second earlier in the video.

[jbenet]

the only way to know for sure is to comment it out and see if it stops.

On Sunday, May 5, 2013 at 5:00 PM, Daniel Windham wrote:

This a) shouldn't happen and if it did b) shouldn't cause the problem you're seeing.
a) This shouldn't happen because, when a user hasn't sought to a new location, the progress bar only updates to keep pace with the youtube video. This update and the event it throws, which triggers the method you posted, is a minimal amount of code to run, and would happen long before the youtube video progressed to a new time. This assumes the youtube player progresses at regular intervals - if it progressed multiple intervals at once, this might cause a bug.
b) This shouldn't cause the problem you're seeing, because the undesired seek would seek to the last offset that was registered correctly, likely only one frame earlier than the one playing. In the video you show, the seek is to some different part of the video, not simply to 0.1 second earlier in the video.

—
Reply to this email directly or view it on GitHub (#116 (comment)).