Don't throttle readahead until download is fast enough

RESOLVED FIXED in Firefox 55

Status

()

Core
Audio/Video: Playback
P1
normal
RESOLVED FIXED
a year ago
6 months ago

People

(Reporter: jwwang, Assigned: jwwang)

Tracking

unspecified
mozilla55
Points:
---

Firefox Tracking Flags

(firefox55 fixed)

Details

MozReview Requests

()

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(2 attachments)

(Assignee)

Description

a year ago
Per bug 1347174 comment 37, we want to download as much as possible for slow connections to get a decent playback quality.

Therefore, we should only turn on throttling when download is fast enough to continue playback without stopping for buffering.
(Assignee)

Updated

a year ago
Assignee: nobody → jwwang
Priority: -- → P1
See Also: → bug 1347174
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
(Assignee)

Updated

a year ago
Attachment #8867595 - Flags: review?(cpearce)
Attachment #8867596 - Flags: review?(cpearce)

Comment 3

a year ago
mozreview-review
Comment on attachment 8867595 [details]
Bug 1364001. P1 - add an API to throttle download.

https://reviewboard.mozilla.org/r/139148/#review142390

Good, thanks!
Attachment #8867595 - Flags: review?(cpearce) → review+

Comment 4

a year ago
mozreview-review
Comment on attachment 8867596 [details]
Bug 1364001. P2 - throttle download when we can play through.

https://reviewboard.mozilla.org/r/139150/#review142392
Attachment #8867596 - Flags: review?(cpearce) → review+
(Assignee)

Comment 5

a year ago
Thanks!

Comment 6

a year ago
Pushed by jwwang@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/baa6989bbb1c
P1 - add an API to throttle download. r=cpearce
https://hg.mozilla.org/integration/autoland/rev/8518f6af32c2
P2 - throttle download when we can play through. r=cpearce

Comment 7

a year ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/baa6989bbb1c
https://hg.mozilla.org/mozilla-central/rev/8518f6af32c2
Status: NEW → RESOLVED
Last Resolved: a year ago
status-firefox55: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55

Comment 8

a year ago
(In reply to JW Wang [:jwwang] [:jw_wang] from comment #0)
> Per bug 1347174 comment 37, we want to download as much as possible for slow
> connections to get a decent playback quality.
> 
> Therefore, we should only turn on throttling when download is fast enough to
> continue playback without stopping for buffering.

(In reply to Chris Pearce (:cpearce) from comment #3)
> Comment on attachment 8867595 [details]
> Bug 1364001. P1 - add an API to throttle download.
> 
> https://reviewboard.mozilla.org/r/139148/#review142390
> 
> Good, thanks!

is there any preference to load entire media w/o checking/bypassing and throttling?

"media.cache_resume_threshold"
and "media.cache_readahead_limit" to 999999.


can we set it to -1 = unlimited? so all the media is loaded always

I ask because in our country speeds fluctuates a lot,
so we basically just open tabs in background and after some time switch to it and watch it so it's not buffering or anything and smooth as our connection is very unreliable, sometimes fast sometimes very slow
Flags: needinfo?(jwwang)
Flags: needinfo?(cpearce)
jigsawmode: with the change in this bug, we should only throttle the download if we estimate that we can download it at a rate faster than it would be played. This change will be in tomorrow's Nightly build.

It would be great if you could download a Nightly build tomorrow from https://www.mozilla.org/en-US/firefox/channel/desktop/ and test that and confirm whether you see this behaviour on your network?
Flags: needinfo?(cpearce)

Comment 10

a year ago
(In reply to Chris Pearce (:cpearce) from comment #9)
> jigsawmode: with the change in this bug, we should only throttle the
> download if we estimate that we can download it at a rate faster than it
> would be played. This change will be in tomorrow's Nightly build.
> 
> It would be great if you could download a Nightly build tomorrow from
> https://www.mozilla.org/en-US/firefox/channel/desktop/ and test that and
> confirm whether you see this behaviour on your network?

Thank you Sure will do that but 
Irrelevant of the connection? is there any preference to load entire media w/o checking/bypassing and throttling?
Just for eg say want to play at 3x normal speed but connection starts with good speeds but **** while watching(connection is flaky like i said that's why want full download/buffered in background)

"media.cache_resume_threshold"
and "media.cache_readahead_limit" to 999999.


can we set it to -1 = unlimited? so all the media is loaded always irrespective of connection speeds?
Flags: needinfo?(cpearce)
(In reply to jigsawmode from comment #10)
> (In reply to Chris Pearce (:cpearce) from comment #9)
> > jigsawmode: with the change in this bug, we should only throttle the
> > download if we estimate that we can download it at a rate faster than it
> > would be played. This change will be in tomorrow's Nightly build.
> > 
> > It would be great if you could download a Nightly build tomorrow from
> > https://www.mozilla.org/en-US/firefox/channel/desktop/ and test that and
> > confirm whether you see this behaviour on your network?
> 
> Thank you Sure will do that but 
> Irrelevant of the connection? is there any preference to load entire media
> w/o checking/bypassing and throttling?
> Just for eg say want to play at 3x normal speed but connection starts with
> good speeds but **** while watching(connection is flaky like i said that's
> why want full download/buffered in background)
> 
> "media.cache_resume_threshold"
> and "media.cache_readahead_limit" to 999999.
> 
> 
> can we set it to -1 = unlimited? so all the media is loaded always
> irrespective of connection speeds?

Setting those prefs to a large number should give you the behaviour you want.
Flags: needinfo?(jwwang)
Flags: needinfo?(cpearce)

Comment 12

a year ago
(In reply to Chris Pearce (:cpearce) from comment #11)
> (In reply to jigsawmode from comment #10)
> > (In reply to Chris Pearce (:cpearce) from comment #9)
> > > jigsawmode: with the change in this bug, we should only throttle the
> > > download if we estimate that we can download it at a rate faster than it
> > > would be played. This change will be in tomorrow's Nightly build.
> > > 
> > > It would be great if you could download a Nightly build tomorrow from
> > > https://www.mozilla.org/en-US/firefox/channel/desktop/ and test that and
> > > confirm whether you see this behaviour on your network?
> > 
> > Thank you Sure will do that but 
> > Irrelevant of the connection? is there any preference to load entire media
> > w/o checking/bypassing and throttling?
> > Just for eg say want to play at 3x normal speed but connection starts with
> > good speeds but **** while watching(connection is flaky like i said that's
> > why want full download/buffered in background)
> > 
> > "media.cache_resume_threshold"
> > and "media.cache_readahead_limit" to 999999.
> > 
> > 
> > can we set it to -1 = unlimited? so all the media is loaded always
> > irrespective of connection speeds?
> 
> Setting those prefs to a large number should give you the behaviour you want.

what will be default value in tomorrow's build?

you forgot to answer two important things,
Can i set it to -1 as unlimited or what should it be the maximum to trigger that behavior if -1 is not an option?
Sorry for asking stupid questions.
Flags: needinfo?(cpearce)
(Assignee)

Comment 13

a year ago
(In reply to jigsawmode from comment #12)
> what will be default value in tomorrow's build?
"media.cache_readahead_limit" = 60, "media.cache_resume_threshold"=30.

 
> you forgot to answer two important things,
> Can i set it to -1 as unlimited
No.

> or what should it be the maximum to trigger
> that behavior if -1 is not an option?
> Sorry for asking stupid questions.
Set "media.cache_readahead_limit" to 999999.
Flags: needinfo?(cpearce)
Depends on: 1367950

Comment 14

6 months ago
It seems on some html5 players, these settings might result in high cpu util in a universal crt thread responsible for interacting with the windows decoders.
You need to log in before you can comment on or make changes to this bug.