Closed
Bug 1313955
Opened 8 years ago
Closed 8 years ago
Paused videos in background tabs change time position slightly when the tab is selected
Categories
(Core :: Audio/Video: Playback, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla52
Tracking | Status | |
---|---|---|
firefox52 | --- | verified |
People
(Reporter: caspy77, Assigned: u480271)
References
(Blocks 1 open bug)
Details
Attachments
(3 files, 1 obsolete file)
STR:
1) Open a youtube video such as this https://youtu.be/WqJS_FqZNJ0
2) Pause the video
3) Open a new tab or switch to another tab in the same window
4) Wait for 15 seconds and switch back
The image will usually change slightly as though it advanced either forward or backward a frame or more
I've tested in a fresh profile and still saw the issue.
I'm on Windows 10, 51.0a2 (2016-10-29) (64-bit)
Let me know if you need more info.
Currently receiving webm on youtube.
I've looked at this and it appears to be a problem with recovering from dormant mode./
Relevant parts of the log:
[MediaPlayback #3]: D/MediaDecoder Decoder=7f38190c4800 StopPlayback()
[MediaPlayback #3]: V/MediaDecoder VideoSink=7f381915d0e0 playing (1) -> (0)
[MediaPlayback #3]: V/MediaDecoder VideoSink=7f381915d0e0 playing video frame 40673000 (id=418) (vq-queued=11)
Pause video and video sink is trimmed to 1 frame beginning at 40673000.
[MediaPlayback #5]: D/MediaDecoder [AccurateSeekTask] Decoder=7f38190c4800 DropVideoUpToSeekTarget() frame [37370000, 37403000]
[MediaPlayback #5]: D/MediaDecoder [AccurateSeekTask] Decoder=7f38190c4800 DropVideoUpToSeekTarget() pop video frame [37370000, 37403000] target=40636898
Start recovery and seek to 40636898. Hold on that's before the time of the frame in the VideoSink... [snip]
[MediaPlayback #7]: D/MediaDecoder [AccurateSeekTask] Decoder=7f38190c4800 DropVideoUpToSeekTarget() frame [40607000, 40640000]
[MediaPlayback #7]: D/MediaDecoder [AccurateSeekTask] Decoder=7f38190c4800 DropVideoUpToSeekTarget() found video frame [40636898, 40640000] containing target=40636898
[MediaPlayback #7]: D/MediaDecoder Decoder=7f38190c4800 Changed state from SEEKING (to 40636898) to DECODING
[MediaPlayback #7]: D/MediaDecoder Decoder=7f38190c4800 Seek completed, mCurrentPosition=40636898
[MediaPlayback #7]: V/MediaDecoder VideoSink=7f381915d0e0 playing video frame 40636898 (id=423) (vq-queued=1)
Recovered and seek to frame beginning 40607000. But that's the wrong frame and doesn't match what's in the VideoSink. Depending on how far the seek is from the last keyframe, it's possible to see the frame before switching to dormant before the decode presents the "new" frame that's a couple of frames in the past.
Should seek to mMediaSink->GetPosition() to match what the frame that VideoSink kept.
Comment hidden (mozreview-request) |
Updated•8 years ago
|
Priority: -- → P3
Comment 7•8 years ago
|
||
mozreview-review |
Comment on attachment 8806184 [details]
Bug 1313955 - Dormant recovery seek uses wrong time.
https://reviewboard.mozilla.org/r/89680/#review89096
Attachment #8806184 -
Flags: review?(jwwang) → review+
Comment hidden (mozreview-request) |
Comment 9•8 years ago
|
||
mozreview-review |
Comment on attachment 8806184 [details]
Bug 1313955 - Dormant recovery seek uses wrong time.
https://reviewboard.mozilla.org/r/89680/#review89136
::: dom/media/MediaDecoderStateMachine.cpp:1152
(Diff revision 2)
> if (!aDormant) {
> return true;
> }
> SeekJob seekJob;
> - seekJob.mTarget = SeekTarget(mMaster->mCurrentPosition,
> + int64_t seekTargetTime =
> + mMaster->mMediaSink->IsStarted() ? mMaster->mMediaSink->GetPosition() :
mMaster->GetClock() : mMaster->GetMediaTime();
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 13•8 years ago
|
||
Pushed by dglastonbury@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a8211df712a7
Dormant recovery seek uses wrong time. r=jwwang
Assignee | ||
Comment 14•8 years ago
|
||
MozReview-Commit-ID: 4ZPOU3aPg8b
Attachment #8806185 -
Attachment is obsolete: true
Assignee | ||
Comment 15•8 years ago
|
||
Anthony, do we care about requesting uplift for this?
Flags: needinfo?(ajones)
(In reply to Dan Glastonbury :kamidphish from comment #15)
> Anthony, do we care about requesting uplift for this?
Given that you have a patch, we can let RelMan decide if they want to take it.
Flags: needinfo?(ajones)
Comment 17•8 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox52:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Updated•8 years ago
|
Flags: qe-verify+
Comment 18•8 years ago
|
||
I reproduced this issue using Fx 52.0a1, build ID: 20161030030204, on Windows 10 x64.
I can confirm this issue is fixes, I verified using Fx 52.0b4, build ID: 20170206101855, on Windows 10 x64.
Cheers!
You need to log in
before you can comment on or make changes to this bug.
Description
•