Increasing playbackRate makes currentTime incorrect
Reported by
pieter-j...@theoplayer.com,
Jul 11 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Set up a page with a <video> element containing this video as a source (Google Drive link to MP4: https://drive.google.com/file/d/0B4O8_lWw1rbEMXRlLWJVcmg3elE/view?usp=sharing) 2. Set <video>'s playbackRate to 4 3. Play for about 2 minutes of video time. 4. Pause the video 5. check video.currentTime 6. set video.currentTime = video.currentTime What is the expected behavior? The frame being showed should not change What went wrong? The frame being showed is changed to an earlier frame. Did this work before? N/A Is it a problem with Flash or HTML5? N/A Does this work in other browsers? N/A Chrome version: 59.0.3071.115 Channel: stable OS Version: OS X 10.12.5 Flash Version: Contents of chrome://gpu: This works in Edge and Safari without any issues. Chrome seems to struggle and reports the wrong currentTime after having playbackRate > 1 for a certain time. The longer you let the video play, the greater the difference will be.
,
Jul 12 2017
There was a tiny difference (1-2 frame?) when I attempted to repro this on Linux. I will look into whether or not the problem is worse on Mac.
,
Jul 12 2017
Yes, when running for a low amount of time, there is a tiny difference. When running for a longer time, the difference becomes bigger and can run up to even seconds of difference. It would be my expectation that currentTime is always related to the current frame being shown. Clamping the time on paused would in my opinion result in strange behaviour, being that the currentTime would become larger, and then go back down on pause due to the clamping.
,
Jul 24 2017
Quickly wanted to follow up on this. It appears the problem becomes a lot worse in case you run a long video, going to a difference of tens of seconds and potentially more.
,
Jul 25 2017
In an additional note, we observed that removing the audio track from the source video does not change anything in regards to behaviour. It appears to be a video pipeline issue. The same video without audio track can be found here: https://drive.google.com/open?id=0B4O8_lWw1rbEMXRlLWJVcmg3elE
,
Jul 25 2017
Note: last message had wrong link. Correct one is: https://drive.google.com/open?id=0B4O8_lWw1rbENkhLenRITHBRVEk
,
Jul 25 2017
I also noticed that playing the video in 4x speed c#1, the video seems somtimes stops at 9:24, rather than 10:03. I also had one instance of the video reaching the end, but the audio keept going. I am taking a deeper look into this.
,
Aug 8 2017
Hello! It seems that the video provided has some serious anomalies. There are several segments that are running at tens of thousands of frames per second. For example, at timestamp 551.918033, there are 130972 frames of length 1/90000s. This likely explains the problems with current time. Are you able to get a repro for the original bug on any other video? I have tried the repro steps with a properly encoded mp4. For that video, everything seems fine, and there is at most a 1 frame difference, regardless of how long the video has been playing for.
,
Aug 26 2017
If ever you are able to reproduce this bug, please re-open it. |
|||
►
Sign in to add a comment |
|||
Comment 1 by dalecur...@chromium.org
, Jul 11 2017Owner: tguilbert@chromium.org
Status: Assigned (was: Unconfirmed)