Increasing playbackRate introduces currentTime drift

Assigned to



Audio/Video: Playback
6 months ago
4 months ago


(Reporter: pieter-jan.speelmans, Assigned: chunmin)


({compat, stale-bug})

56 Branch
compat, stale-bug

Firefox Tracking Flags

(Not tracked)




6 months ago
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:
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


6 months ago
Component: Untriaged → Audio/Video: Playback
Product: Firefox → Core

Comment 1

6 months ago
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

Comment 3

6 months ago
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:
(In reply to pieter-jan.speelmans from comment #3)
> The same video without audio track can be found here:

No. This video contains audio data.
Priority: -- → P1
Keywords: compat
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.
Keywords: stale-bug
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.