Closed Bug 1694634 Opened 3 years ago Closed 3 years ago

Audio file doesn’t restart if skipping to the end of the seekbar while in loop mode

Categories

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

defect

Tracking

()

RESOLVED FIXED
89 Branch
Tracking Status
firefox-esr78 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- wontfix
firefox89 --- fixed

People

(Reporter: emilghitta, Assigned: alwu)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: regression)

Attachments

(5 files)

Attached image audioMediaLoop.gif

Affected versions

  • Firefox 86.0 (BuildId:20210222142601)
  • Firefox 87.0b2 (BuildId:20210223185702)
  • Firefox 88.0a1 (BuildId:20210223230332)
  • Firefox 78.8.0esr (BuildId:20210217034806)

Affected platforms

  • Windows 10 64bit
  • Ubuntu 20.04 64bit
  • macOS 10.14

Steps to reproduce

  1. Launch Firefox.
  2. Access the following link.
  3. Right click on the seekbar.
  4. Click on the “loop” option from the context menu.
  5. Click on the seekbar to skip to the end of the audio file.

Expected result

  • The audio is restarted successfully since the loop mode is active.

Actual result

  • The audio is not restarted. It seems that sometimes it remains frozen at 2:55 or at 0:00.

Regression Range

Notes

  • For further information regarding this issue please observe the attached screencast.
  • Please note that it is possible that you may have to refresh the page and redo steps 3 - 5 a couple of times (if you can't reproduce it from the first try).

Hi Alastor!

I tried searching for the exact regressor but since the regression is too old I keep on hitting 4:50.04 INFO: There are no build artifacts for these changesets (they are probably too old).

Taking a look at the generated pushlog it seems that you have previously worked on the loop functionality in Bug 1505972.

Can you please take a look? And sorry in advance if I pointed on the wrong regressor bug.

Thank you!

Flags: needinfo?(alwu)

That is possible, will take a look later.

Assignee: nobody → alwu
Flags: needinfo?(alwu)
Priority: -- → P3
Has Regression Range: --- → yes
Has STR: --- → yes

I'm working on this today, and will submit my patches later after I finish testing them.

When audio has reaches to EOS, we will call its Finish() to make it ended, and the audio queue can be reopen again by pushing new data.

Before we reopen the audio queue again, we should not start playback. Otherwise, AudioSinkWrapper would resolve end promise immediately [1]. The concept of reopening audio queue doesn't exist for other classes that access to the audio queue.

Therefore, we should set mIsPrerolling=true in order to wait for new data that can reopen the queue again.

[1] https://searchfox.org/mozilla-central/rev/166dfa51ee50207a253fc577b9a596e64f24258c/dom/media/mediasink/AudioSinkWrapper.cpp#156-165

Depends on D110878

Depends on D110879

At the time I worked on this state, it was only used for audio. There were some problems blocking the implementation for video, but the comment wasn't updated.

So we should correct the comment to make it reflect the real situation.

Depends on D110880

Pushed by alwu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/288a653bc445
part1 : add debug log for media decoder. r=bryce
https://hg.mozilla.org/integration/autoland/rev/1ffca5142b37
part2 : should preroll data to reopen the audio queue before starting the playback. r=bryce
https://hg.mozilla.org/integration/autoland/rev/e11fe857b496
part3 : add wpt test. r=bryce
https://hg.mozilla.org/integration/autoland/rev/6d1ba29557a8
part4 : correct the comment for LoopingDecodingState. r=bryce
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/28409 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: