Closed Bug 1532495 Opened 11 months ago Closed 8 months ago

A looping webm will stop playing in a broken state if left in a background tab for long enough.

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla68
Tracking Status
firefox-esr60 --- unaffected
firefox66 --- wontfix
firefox67 --- wontfix
firefox67.0.1 --- wontfix
firefox68 --- fixed

People

(Reporter: twisniewski, Assigned: alwu)

References

(Regression, )

Details

(Keywords: regression)

Attachments

(2 files)

The given webm, if left looping in a background tab, will soon stop playing entirely and will no longer play back properly.

STR:

  1. load https://mltshp.com/r/1FHQ2.webm
  2. right-click it and set it to loop
  3. click to play it
  4. open a new tab in the same window
  5. wait some time (20+ seconds on my system).
  6. return to the tab with the looping webm.
  7. notice it has stopped playing, and will not play properly anymore.

This was reported at https://webcompat.com/issues/25520 and has been reproduced on Linux, OSX and Windows 10 on today's nightly build.

Summary: A ;ooped webm will stop playing in a broken state if left in a background tab for long enough. → A looping webm will stop playing in a broken state if left in a background tab for long enough.

Thanks, Thomas for filing this. I was the original reporter on the webcompat repo (the Mozilla.org site directed me to file there?). In any case, happy to answer any follow-on questions that may arise.

No problem, Brad. It doesn't matter where a bug gets reported, as long as it ends up in the right place so it gets fixed. There was just not much we could do on webcompat.com, as this seems to be a playback issue with Firefox itself.

I can reproduce this in a current Nightly build. It happens 10 seconds after the looping video tab is hidden - this seems to be a problem recovering from background video decoders being suspended. I toggled the pref media.suspend-bkgnd-video.enabled and the problem is no longer present.

CCing alwu and jya, who have worked on looping related stuff recently.

Priority: -- → P3

I can reproduce this issue on the latest Nightly, will check it later.

Assignee: nobody → alwu
See Also: → 1304480

When we resume decoding when the video becomes visible, we would start a video-only-seek and would like to set the timeThreshold, which is used to control droping frame in demuxer [1], to the current clock or next available key frame time [2].

However, as the only key frame of this file [3] is the first frame, so when we start request video data from non-start position, all the other frames which are non-keyframes would be discarded, which would result in getting video's EOS.

In this bug, when we resume decoding for 1FHQ2.webm, it goes to the decoding state after finishing seeking, but we stuck there and didn't go to completed state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping.

So what will happen after we get video EOS?

If the media contains audio, you would see that the video frame is freezing but the audio is still playing. You can reproduce this situation by playing gizmo-noaudio.webm [4] when resuming the video from suspending decoding.

If the media doesn't contain audio, it should be stopped immediately because the decoding has been ended.

[1] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaFormatReader.cpp#2514-2528
[2] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#1734-1752
[3] https://mltshp.com/r/1FHQ2.webm
[4] dom/media/test/gizmo-noaudio.webm


In this bug, when we resume decoding for 1FHQ2.webm, it goes to the decoding state after finishing seeking, but we stuck there and didn't go to completed state. It made the MDSM couldn't notify media element playback has ended in order to restart the file again because of looping.

The reason we stuck is because the incorrect checking prevents us changing the state [5], this case only works for seamless looping, because seamless looping doesn't need to go through completed state, it can restart decoding by itself. The normal looping process is that, goes to completed state first, notify playback ended, and finally media element would call seek to the start position. However, seamless looping can stay in loopingDecoding state and repeating the looping without going to other states.

[5] https://searchfox.org/mozilla-central/rev/99a2a5a955960b0e58ceade1db1f7652d9db4ba1/dom/media/MediaDecoderStateMachine.cpp#2281-2287

The normal looping process is that, goes to completed state first, notify playback ended, and finally media element would call seek to the start position in order to start looping again.

However, if we're in the seamless looping mode, we can stay in loopingDecoding state and repeating the looping without going to other states. Otherwise, we should go to completed state if decoding has ended.

Add test to to ensure that the looping video (without audio track) which has been suspended can continute to playback correctly after we resume video decoding.

Attachment #9063392 - Attachment description: Bug 1532495 - only skip the 'completed' state during seamless looping mode. → Bug 1532495 - part1 : only skip the 'completed' state during seamless looping mode.
Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5567ad616234
part1 : only skip the 'completed' state during seamless looping mode. r=jya
https://hg.mozilla.org/integration/autoland/rev/126a59b083f6
part2 : add test 'test_background_video_resume_looping_video_without_audio.html' r=jya
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Blocks: 1551050

:alwu,
This is regressed by Bug 1505972.
See Bug 1551050. Scrolling page up and down causes the problem too.

Are you going to lift this to 67?

Flags: needinfo?(alwu)
Keywords: regression
Regressed by: 1505972

s/lift/uplift/

Duplicate of this bug: 1551050

As the 67 are going to be on Release soon, I don't want to uplift the fix without having much time to see if it would cause any regression or not. So I prefer not to uplift this bug.

Flags: needinfo?(alwu)
QA Whiteboard: [qa-68b-p2]
You need to log in before you can comment on or make changes to this bug.