User Agent: 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 Steps to reproduce: 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 a while (at least 2 minutes) of video time. 4. Pause the video 5. check video.currentTime 6. set video.currentTime = video.currentTime It appears there is a drift between the video frame which is shown and the currentTime which is reported. When the time playing with an increased playbackRate becomes longer, the timedrift appears to be bigger as well (a few minutes will give you frames, while tens of minutes can give seconds of difference). This works fine in browsers such as Edge and Safari. Actual results: The frame being showed is changed to an earlier frame. Expected results: The frame being showed should not change
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core
Quickly wanted to follow up if there has been any progress 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.
I think this is an AudioStream issue.
Assignee: nobody → cchang
I thought so first, but it appears I can reproduce this still when stripping out the audio from the video. Is it likely there is a different cause here? The same video without audio track can be found here: https://drive.google.com/open?id=0B4O8_lWw1rbEMXRlLWJVcmg3elE
(In reply to pieter-jan.speelmans from comment #3) > The same video without audio track can be found here: > https://drive.google.com/open?id=0B4O8_lWw1rbEMXRlLWJVcmg3elE No. This video contains audio data.
Apologies: wrong link. https://drive.google.com/open?id=0B4O8_lWw1rbENkhLenRITHBRVEk
This is an assigned P1 bug without activity in two weeks. If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword. Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
You need to log in before you can comment on or make changes to this bug.