[M92 merge] Lift WebMediaPlayer limits much higher.
The existing limits suffer from two problems:
(1) They were applied without sufficient notice, leaving many apps suddenly broken.
(2) They are incorrectly applied to audio-only media streams when the intent is mainly to cap much heavier video objects.
The limits will only be lowered after
(1) Finch controls are in place.
(2) Enterprise policy overrides are in place.
(3) An intent to intervene has been published.
(4) Logic has been fixed to distinguish between media streams and video.
(5) A web.dev article has been published about best practices.
BUG=1144736,1232649
Change-Id: I895a9339856683744a7ac2aff1b602194607d80f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3057112
Commit-Queue: Chris Hamilton <chrisha@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/branch-heads/4515@{#1869}
Cr-Branched-From: 488fc70865ddaa05324ac00a54a6eb783b4bc41c-refs/heads/master@{#885287}
diff --git a/content/renderer/media/media_factory.cc b/content/renderer/media/media_factory.cc
index 58965b40..b5d5ef4 100644
--- a/content/renderer/media/media_factory.cc
+++ b/content/renderer/media/media_factory.cc
@@ -115,17 +115,10 @@
namespace {
-// This limit corresponds to the per-platform 99.9th %ile of the number of
-// WebMediaPlayers used by a single frame, as measured in March 2021. This
-// tries to balance minimizing web platform breakage and preventing abusive
-// API usage. See http://crbug.com/1144736#c49
-constexpr size_t kDefaultMaxWebMediaPlayers =
-#if defined(OS_ANDROID)
- 40;
-#else
- // All desktop platforms share the same value.
- 75;
-#endif
+// This limit is much higher than it needs to be right now, because the logic
+// is also capping audio-only media streams, and it is quite normal for their
+// to be many of those. See http://crbug.com/1232649
+constexpr size_t kDefaultMaxWebMediaPlayers = 1000;
size_t GetMaxWebMediaPlayers() {
static const size_t kMaxWebMediaPlayers = []() {
