Open Bug 1853659 Opened 2 years ago Updated 9 months ago

No Range-Request for short slowly transferred audios

Categories

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

Firefox 116
defect

Tracking

()

UNCONFIRMED

People

(Reporter: bugreport, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/116.0

Steps to reproduce:

Take a relatively short (around 3 minutes) constant bitrate 128kbps mp3 file. Set up a Webserver emulating a slow but just sufficiently fast connection, i.e. delivering this audio in realtime, without initial burst. This can be achieved with e.g. Apache using the following configuration:

LoadModule ratelimit_module libexec/apache2/mod_ratelimit.so

Listen 8090

<VirtualHost *:8090>
DocumentRoot /var/www/html/ratelimit
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 16
#SetEnv rate-initial-burst 256
<Directory "/var/www/html/ratelimit">
Require all granted
</Directory>
</VirtualHost>

The rate limit 16 corresponds to 128kbps (=16kByte/s). The test audio mp3-file (say test.mp3) has to be in the folder /var/www/html/ratelimit/ .

Load the test audio into the browser via http://localhost:8090/test.mp3
(or alternatively into a test-page with an <audio> tag and this url as its source. Bug happens in both cases)

Click play and wait until the audio starts playing (works with a delay of maybe 4secs). Click somewhere into the timeline into a region that has not been loaded yet.

Note that the described bug is NOT a bug of Apache, as I originally observed it with our own Server (programmed in Java) which for certain reasons has to have this behaviour (delivery in realtime, without initial burst, but supporting range-requests).

Note further that it will affect all users with limited connection speed. Audios with very high audio bitrate probably will be affected much more frequently ...
It might be that the bug 1850503 is a direct consequence of this one.

Actual results:

After clicking into the timeline into a region that has not been loaded yet, the browser does not do any range-request (according to the developer tools). It sticks to the current request and waits until the loading reaches the desired position (which can take up to 3 minutes for a 3-minute file).

Expected results:

After clicking into the timeline into a region that has not been loaded yet, the browser should send a range request and resume playing after a short delay of maybe 4 seconds.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking
Product: Firefox → Core
Component: Networking → Audio/Video: Playback

This is a suitable testfile for the described bug. Length approx 1 minute. 128kbps, cbr, mp3

The key bit here - "After clicking into the timeline into a region that has not been loaded yet, the browser does not do any range-request (on the web server)".

Not sure who might be best to look at this. ni to Alwu for the some initial feedback.

ms2 - Thanks for the details report and STR!

Flags: needinfo?(alwu)

Bug 1850503 - Audio playback hangs after sliding the time ruler
Similar bug filed by the same user related to scrubber positioning and playback.

See Also: → 1850503
Severity: -- → S3
Flags: needinfo?(alwu)
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: