Delayed audio after muting and unmuting looped media
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr102 | --- | unaffected |
| firefox-esr115 | --- | verified |
| firefox114 | --- | wontfix |
| firefox115 | --- | wontfix |
| firefox116 | --- | verified |
People
(Reporter: karlt, Assigned: alwu)
References
(Regression, )
Details
(Keywords: regression)
Attachments
(1 file)
|
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr115+
|
Details | Review |
- Load data:text/html,<audio%20controls%20loop%20src="https://philips.s3.eu-central-1.amazonaws.com/Rudolf/VfE_html5.mp4">
- Play audio.
- Listen to the acorn hitting the bird just before 0:21.
- Wait (or seek to near the end then wait) for audio to loop back to beginning.
- Mute for a few seconds.
- Unmute before 0:21.
- Listen for acorn again.
Expect: acorn sound at 0:21
Actual: acorn sound is delayed by something like the duration for which the audio was muted.
Seeking back to before 0:21 plays the acorn sound at the correct time.
This does not reproduce if steps 4 and 5 are interchanged.
| Reporter | ||
Comment 1•2 years ago
|
||
Toggling media.seamless-looping-video has no effect on the audio element.
Setting media.seamless-looping to false produces expected behavior.
Reproduces also with video: data:text/html,<video%20controls%20loop%20src="https://philips.s3.eu-central-1.amazonaws.com/Rudolf/VfE_html5.mp4">
| Reporter | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
Set release status flags based on info from the regressing bug 1262276
:alwu, since you are the author of the regressor, bug 1262276, could you take a look? Also, could you set the severity field?
For more information, please visit BugBot documentation.
| Reporter | ||
Comment 3•2 years ago
|
||
The old revisions in the regression range can be built with https://hg.mozilla.org/mozilla-central/rev/53badec13c4cf6a638e8bd5ee360d8f316aba917 applied (but not on try). This identifies the changeset triggering the regression as https://hg.mozilla.org/integration/autoland/rev/e43f99440e29
Updated•2 years ago
|
| Assignee | ||
Comment 4•2 years ago
|
||
Sorry for late reply, I am going to take a look at this today.
| Assignee | ||
Comment 5•2 years ago
|
||
When seamless looping is on, sample's timestamp would only be adjusted
once when they fist get pushed into the media queue.
When re-queuing sample back to the audio queue from the
mProcessedSPSCQueue, we don't need to apply timestamp adjustment
again. Otherwise, it would result in incorrect audio time so that the
AudioSink would never discard samples [1] during muting, causing audio
can't be rendered in the correct moment.
Comment 7•2 years ago
|
||
| bugherder | ||
Comment 8•2 years ago
|
||
Can we land a test for this?
| Assignee | ||
Comment 9•2 years ago
|
||
We're not able to write a test for this, see this.
Comment 10•2 years ago
|
||
Did you want to nominate this for ESR115 uplift? It grafts cleanly.
| Assignee | ||
Comment 11•2 years ago
|
||
Comment on attachment 9340586 [details]
Bug 1838756 - do not adjust timestamp again for samples, which has been adjusted, when pushing them back to the audio queue.
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: This fixes the problem where looping audio sometime can't play sound correctly
- User impact if declined: audio won't be able to play sound, only silence
- Fix Landed on Version: 115
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): This didn't introduce a new functionality or a big architecture change, we only disable the incorrect time adjustment on a specific case where looping audio gets muted.
Comment 12•2 years ago
|
||
Comment on attachment 9340586 [details]
Bug 1838756 - do not adjust timestamp again for samples, which has been adjusted, when pushing them back to the audio queue.
Approved for 115.1esr.
Comment 13•2 years ago
|
||
| uplift | ||
Comment 14•2 years ago
|
||
| bugherder uplift | ||
Updated•2 years ago
|
Comment 15•2 years ago
|
||
Hello I have managed to reproduce the issue with Firefox 116.0a1(2023-06-10) on Ubuntu 22.04. I can confirm that the issue is fixed with firefox 117.0a1(2023-07-11), 116.0b3, 115.1.0esr(treeherder build from comment 14) on Ubuntu 22.04, Mac12 and Windows 10. I will update the corresponding flags.
I would like to mention that firefox 115.0.2esr is still affected by this issue.
Have a nice day!
Description
•