New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 754608 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Aug 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

2.7%-13.1% regression in webrtc_perf_tests at 19308:19309

Project Member Reported by brandtr@chromium.org, Aug 11 2017

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Aug 11 2017

All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=754608

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=33e23dbcc607524ef44d9660405b1733a86602af0e678dc25c49bb71d4d08f64


Bot(s) for this bug's original alert(s):

webrtc-android-tests-nexus5-kitkat
webrtc-win-large-tests
Cc: holmer@chromium.org
Owner: philipel@chromium.org
Status: Assigned (was: Untriaged)
Increased memory usage due to https://codereview.webrtc.org/2994093002.

philipel: Please close if the increase is within the expectations :)

Comment 3 by holmer@chromium.org, Aug 11 2017

Cc: sprang@chromium.org
It's a bit unfortunate that it has such a big memory impact on large meetings (10% mem increase for 15 person meetings).

It seems like it would be pretty safe to reduce from 512 to, say, 128 and still not hit the bug. WDYT?

sprang@, do you know how common frames larger than 100 packets are?
In practice the change in memory usage is not that big. A buffer of 512 packets has the size of ~720 kB, and in the context of running webrtc in chrome it doesn't matter much. Also, this is a temporary workaround, so it should be gone in M63.

Even if we wanted to reduce the start size there is a risk of frames being larger than 128 packets when doing screensharing.


Status: WontFix (was: Assigned)

Sign in to add a comment