Open Bug 1592601 Opened 6 years ago Updated 3 years ago

When streaming, <audio> buffer persist after reload, producing audible glitches when playing again.

Categories

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

defect

Tracking

()

People

(Reporter: mozilla-bugzilla, Unassigned)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

Simple <audio>, streaming over http or https:

<audio src="http://example.com/stream" controls="controls" preload="none"></audio>

See attachment for minimal test files with real world streams.

  • let stream for ~20s
  • click pause
  • reload page (Ctrl-R, F5)
  • click play

Note: This situation happens a lot when listening to web radio on mobile:

  • you leave wifi, or lose network otherwise
  • audio gets stuck/stalled
  • no way to hit stop/play because player (e.g. JS framework) is stuck
  • you reload the page, hit play

Actual results:

  • stream starts playing, but with severe glitches; portions of the stream before reload can be heard interspersed
  • progress indicator (counter/timer) shows the time from before reload (0:20 instead of... less)

Tested on:

  • 66.0.3 64bit on Ubuntu
  • 70.0 64bit on Arch Linux
  • 70.0 64bit on Win10
  • 69.0.3 64bit on macOS 10.13.6

Expected results:

  • should stream properly

  • counter/timer should start at 0:00 + whatever buffering is applied

  • buffer should be flushed, I guess

  • I guess the current behavior is fine for static files, where the buffer can persist.

Summary: When streaming, <audio> buffer persist after reload, producing audible glitches audio when playing again. → When streaming, <audio> buffer persist after reload, producing audible glitches when playing again.
Component: Untriaged → Audio/Video
Product: Firefox → Core

Thanks for the report and the simple reproducer. Confirmed issue locally. Chrome doesn't suffer from this, but has a noticeably longer delay before resuming playback after the reload (presumably because it's rebuffering).

Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
See Also: → 1610427
See Also: 1610427

Bug still present in v76. I've found a simplistic workaround: if the server supports it, append something for cachebusting, e.g. a query string. A fix for the test case above could look like this:

<!DOCTYPE html>
<html>
	<head>
		<script>
			window.onload = function () {
				for (const a of document.getElementsByTagName('audio')) {
					a.src += '?cachebust=' + (+new Date());
				}
			}
		</script>
	</head>
	<body>
		BBC Radio 1: <audio src="http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio1_mf_q" controls="controls" preload="none"></audio><br/>
		WFMU: <audio src="http://stream0.wfmu.org/freeform-128k" controls="controls" preload="none"></audio>
	</body>
</html>

Obviously, this could be as simple as a one-liner, especially server-side.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: