Whole audio file loaded despite preload="metadata"
Categories
(Core :: Audio/Video: Playback, defect)
Tracking
()
People
(Reporter: codesoap, Unassigned)
Details
Attachments
(1 file)
|
59.97 KB,
image/png
|
Details |
The throttling seems to mess up metadata="preload" handling
User Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
When I set the preload attribute of an audio element to "metadata", Firefox does send a request with the "Range" header, but the range contains the whole file. Thus no network traffic is reduced. I can reproduce the problem with this HTML page:
<!doctype html>
<body>
<audio src="http://localhost:8081" preload="metadata" type="audio/ogg"></audio>
</body>
</html>
Actual results:
When I'm running "nc -l 8081" to see the first request that Firefox sends for the audio file, I see this:
GET / HTTP/1.1
Host: localhost:8081
User-Agent: Mozilla/5.0 (X11; OpenBSD amd64; rv:100.0) Gecko/20100101 Firefox/100.0
Accept: audio/webm,audio/ogg,audio/wav,audio/;q=0.9,application/ogg;q=0.7,video/;q=0.6,/;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=0-
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: audio
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache
Expected results:
I would have expected the "Range" header to be limited. E.g. "Range: bytes=0-1000".
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
||
Comment 2•2 years ago
|
||
Thanks for the clear bug report and test case.
(In reply to Richard Ulmer from comment #0)
When I set the preload attribute of an audio element to "metadata", Firefox does send a request with the "Range" header, but the range contains the whole file. Thus no network traffic is reduced. I can reproduce the problem with this HTML page:
The HTTP request is cancelled once the preload=metadata conditions are met by the media playback engine, so network traffic is reduced. Testing with a 100MB Vorbis file and preload=metadata, I see Firefox load ~32kB from the initial request before being cancelled by the media playback engine - the amount transferred will differ depending on attributes of the media being loaded and network connection. After that initial request, Firefox initiates a second HTTP request loading the last ~7kB of the media to compute the media duration.
Chrome behaves the same way, although it fetches different amounts of data in the two requests (~17kB and ~74kB, respectively).
I would have expected the "Range" header to be limited. E.g. "Range: bytes=0-1000".
preload=metadata is just a hint for the user agent, so the observable behaviour may differ between browser implementations or even versions of the same browser. In general, it's difficult to know in advance how much data is sufficient to satisfy the conditions for preload=metadata, so cancelling the in-flight request once sufficient data has been loaded is a trade-off that avoids having to make multiple requests in exchange for possibly fetching more data than is strictly required.
I'll mark this as invalid, since I don't believe this is a bug in our implementation. If you disagree, please reopen the bug with further information.
|
Reporter | |
Comment 3•2 years ago
|
||
|
|
Reporter | |
Comment 4•2 years ago
|
||
Thanks for your feedback, Matthew! I was not aware that Firefox would cancel the first request, but now I finally understand.
I had initially tried to understand the behavior by testing with a local fileserver and simulating a slow network connection using the throttling of the developer console; I have attached a screenshot of this. Apparently the throttling is buggy, since the metadata now takes a long time to load.
Knowing that the bug won't occur in the real world, I have no issue anymore. Would you still like me to open a new bug for the malfunctioning throttle function of the developer console?
Description
•