We enable by default the VP9 hardware decoder on intel GPU.
MozReview-Commit-ID: FzMzbpZErjQ
--HG--
extra : rebase_source : f34c969f7dda1ef24224e982f31d5e43cfae7cc0
8KB by default, otherwise using the next power of two from the given
media.cache.resource-index (but staying within 32B-128KB).
'0' means we don't want to use caching.
MozReview-Commit-ID: 8LmS15Ft2MA
--HG--
extra : rebase_source : 992f377a07b7ab173a64fcfbfe45df1da87df31e
Our canplaythrough logic is opaque to the users, so I expect that our recent
change to throttle when we hit the readahead limit would be confusing to users;
those on a slow connection would want their media to prebuffer, and not expect
the download to stop part way through. They would think that Firefox had
stalled at an arbitrary point for some unknown reason, i.e., they'd think
Firefox was broken. So I think we're better to instead only throttle if the
network is good enough that the user probably doesn't worry about the download
not keeping up with playback.
We should restore the previous behaviour on mobile of throttling when the
download reached the readaheadd limit regardless of canplaythrough or network
speed, as the calculus is different on mobile; the user may also be concerned
about battery life, or hitting their data cap. And often the faster the
cellular network is, the more expensive data on it is.
So this patch changes us to throttle when we reach the readahead limit only if
the network is fast, where fast is defined as being able to stream at twice the
rate estimated to be required to playback without stalling.
It also adds a pref to revert to the old behaviour of not considering the
network speed, which we enable on mobile to restore it to its previous
behaviour.
MozReview-Commit-ID: KLIGaQZV6dX
--HG--
extra : rebase_source : c2e0c6be3158fa661be49d1267d976af43aff6d7
The previous limits were chosen a bit arbitrarily, and didn't trigger racing too often. These limits are also quite arbitrary, but should cause us to race more.
These limits can be removed once we implement bug 1325331 and we can make a fair approximation regarding the cache latency.
MozReview-Commit-ID: CUssxUrs1Wu
--HG--
extra : rebase_source : 0465b921722e398d3b954ad8a5b4531fcebea371
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
Based on the telemetry that landed as part of bug 1336904, Safe Browsing
updates are failing too often: https://mzl.la/2qGkOPS
This should enable browsers on slower networks to reach the update
servers while still putting a reasonable bound on how long the update
thread can be blocked.
MozReview-Commit-ID: 6puVtpMT87K
--HG--
extra : rebase_source : 4b68bb6778b45068bb8a2d0dbdfddfe24a6b022f
Ehsan Akhgari
Nicolas B. Pierron
Jean-Yves Avenard
Honza Bambas
Carsten "Tomcat" Book
Jessica Jong
Ryan VanderMeulen
Dragana Damjanovic
Botond Ballo
Xidorn Quan
Gerald Squelart
Landry Breuil
Kris Maglione
Chris Pearce
Valentin Gosu
Eden Chuang
Jim Mathies
Mike Taylor
Sebastian Hengst
Daosheng Mu
Andreas Farre
Ethan Tseng
Manish Goregaokar
Bruce Sun
Mats Palmgren
Iris Hsiao
btian
Francois Marier
Wes Kocher