Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2545553003:
WebRtcStatsPerfBrowserTest added, a perf test using the new getStats (Closed)
|
Created:
4 years ago by hbos_chromium Modified:
4 years ago CC:
chromium-reviews, feature-media-reviews_chromium.org, phoglund+watch_chromium.org, mcasas+watch+vc_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionWebRtcStatsPerfBrowserTest added, a perf test using the new getStats.
Using the promise-based getStats to collect stats, writes stats after
60+10* seconds of audio and video calling. These will be picked up by
the Chrome Performance Dashboard[1]. E.g. from other browser test: [2].
*(After 60s of ramp-up, performs measurments during a 10s window, to
avoid unstable stats due to variations in ramp-up time.)
This is similar to the WebRtcPerfBrowserTest - renamed
WebRtcInternalsBrowserTest to avoid confusion - which instead uses
chrome://webrtc-internals relying on the old callback-based version of
getStats. Available stats are different.
This performance test only picks up:
- browser_tests / audio_[codec] / send_rate
- browser_tests / audio_[codec] / receive_rate
- browser_tests / video_[codec] / send_rate
- browser_tests / video_[codec] / receive_rate
Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values
[3][4].
For audio codecs: opus, ISAC, G722, PCMU, PCMA.
And video codecs: VP8, VP9, H264.
More stats can be picked up in follow-up CLs, but the new getStats API
has a limited number of stats available.
[1] https://chromeperf.appspot.com/
[2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001c824cd1821be95dc7799134ae9b67
[3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent
[4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived
BUG=670306, 627816
Committed: https://crrev.com/32bafc424946864c744ecfc0cbd83f6d5c18852b
Cr-Commit-Position: refs/heads/master@{#436260}
Patch Set 1 #
Total comments: 4
Patch Set 2 : Fixed EXPECT_EQ to expect the right thing (bug in test, not in code) #
Total comments: 4
Patch Set 3 : Average Bps over 10s window (after 60s rampup) for stable values #Patch Set 4 : Renamed tests: WebRtcStatsPerfBrowserTest and WebRtcInternalsPerfBrowserTest #Patch Set 5 : Addressed nits, rebase, default initialize #
Depends on Patchset: Messages
Total messages: 29 (16 generated)
Patchset #1 (id:1) has been deleted
The CQ bit was checked by hbos@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Description was changed from ========== WebRtcPerformanceTest BUG= ========== to ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). The new getStats API has a limited number of stats. This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... BUG=627816 ==========
Description was changed from ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). The new getStats API has a limited number of stats. This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... BUG=627816 ========== to ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=627816 ==========
hbos@chromium.org changed reviewers: + hta@chromium.org, phoglund@chromium.org
Please take a look, hta and phoglund.
Out of interest, sample run on local machine yields: RESULT audio_opus: bytes_sent= 93506 bytes RESULT audio_opus: bytes_received= 181343 bytes RESULT audio_ISAC: bytes_sent= 89168 bytes RESULT audio_ISAC: bytes_received= 126098 bytes RESULT audio_G722: bytes_sent= 542880 bytes RESULT audio_G722: bytes_received= 542880 bytes RESULT audio_PCMU: bytes_sent= 545220 bytes RESULT audio_PCMU: bytes_received= 545040 bytes RESULT audio_PCMA: bytes_sent= 542880 bytes RESULT audio_PCMA: bytes_received= 542880 bytes RESULT video_VP8: bytes_sent= 12989695 bytes RESULT video_VP8: bytes_received= 12989515 bytes RESULT video_VP9: bytes_sent= 13118074 bytes RESULT video_VP9: bytes_received= 13098741 bytes RESULT video_H264: bytes_sent= 13226586 bytes RESULT video_H264: bytes_received= 13188768 bytes Compared to WebRtcPerfBrowserTest for H264: RESULT bwe_stats_H264: available_send_bw= [3008358,3008358,3008358,3008358,3008358,3008358] bit/s RESULT bwe_stats_H264: available_recv_bw= [0,0,0,0,0,0] bit/s RESULT bwe_stats_H264: target_enc_bitrate= [1700000,1700000,1700000,1700000,1700000,1700000] bit/s RESULT bwe_stats_H264: actual_enc_bitrate= [1729346,1729346,1785108,1666265,1747757,1747757] bit/s RESULT bwe_stats_H264: transmit_bitrate= [1800176,1800176,1741080,1761664,1717024,1737488] bit/s RESULT video_fps_H264: goog_frame_rate_sent= [30,30,27,30,30,30] fps RESULT video_fps_H264: goog_frame_rate_input= [30,30,29,31,31,30] fps RESULT video_total_bytes_H264: bytes_sent= [14348701,14348701,14594998,15885674,16232037,16298287] bytes RESULT video_misc_H264: goog_firs_recv= [0,0,0,0,0,0] RESULT video_misc_H264: goog_nacks_recv= [0,0,0,0,0,0] RESULT video_resolution_H264: goog_frame_width_sent= [480,480,480,480,480,480] pixels RESULT video_resolution_H264: goog_frame_height_sent= [270,270,270,270,270,270] pixels RESULT video_tx_H264: goog_avg_encode_ms= [23,23,26,22,26,29] ms RESULT video_tx_H264: goog_rtt= [4,4,4,3,2,2] ms RESULT video_cpu_usage_H264: goog_encode_usage_percent= [79,79,79,76,75,76] % RESULT audio_bytes: bytes_sent= [252572,252572,258390,288286,296265,297881] bytes RESULT audio_tx: goog_jitter_recv= [2,2,2,1,1,1] ms RESULT audio_tx: goog_rtt= [7,7,7,3,3,3] ms RESULT audio_tx: packets_sent_per_second= [0,null,49.738219895287955,50.04226542688081,49.779458097038436,51.282051282051285] packets RESULT audio_bytes: bytes_recv= [184599,184599,188130,206462,211420,212312] bytes RESULT audio_misc: packets_lost= [0,0,0,0,0,0] frames RESULT audio_rx: goog_jitter_recv= [2,2,2,3,3,3] ms RESULT audio_rates: goog_expand_rate= [0.0145263671875,0.0145263671875,0,0,0,0] % RESULT audio_rates: goog_speech_expand_rate= [0.0057373046875,0.0057373046875,0,0,0,0] % RESULT audio_rates: goog_secondary_decoded_rate= [0,0,0,0,0,0] % RESULT video_fps_H264: goog_frame_rate_recv= [30,30,29,29,29,29] fps RESULT video_fps_H264: goog_frame_rate_output= [29,29,30,29,30,30] fps RESULT video_misc_H264: packets_lost= [0,0,0,0,0,0] frames RESULT video_total_bytes_H264: bytes_recv= [14340999,14340999,14584450,15873308,16213806,16286580] bytes RESULT video_resolution_H264: goog_frame_width_recv= [480,480,480,480,480,480] pixels RESULT video_resolution_H264: goog_frame_height_recv= [270,270,270,270,270,270] pixels RESULT video_rx_H264: goog_current_delay_ms= [34,34,34,35,35,35] ms RESULT video_rx_H264: goog_target_delay_ms= [34,34,34,35,35,35] ms RESULT video_rx_H264: goog_decode_ms= [1,1,1,1,1,1] ms RESULT video_rx_H264: goog_max_decode_ms= [1,1,1,1,1,1] ms RESULT video_rx_H264: goog_jitter_buffer_ms= [23,23,23,24,24,24] ms RESULT video_rx_H264: goog_render_delay_ms= [10,10,10,10,10,10] ms
Description was changed from ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=627816 ========== to ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ==========
https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:22: Bytes received/sent is probably one of the more volatile stats you can get out. You run for 60 seconds and then start looking for stats. What you'll be adding at that point is [10000000003, 10000000013, 10000000050, ...] since many bytes have been already been sent. If the call gets established just a little bit slower or faster it will have a big effect on the average, right? As you can see on the main tests, they're really noisy (and I think they're taken off monitoring for that reason: https://chromeperf.appspot.com/report?sid=edbc402a707f488c03a4e799c1e84662d21...) Are there any other stats could look at here? Otherwise, I honestly think it's better to remove the stabilization period at the start, which benefits bwe and similar more. https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:58: class WebRtcPerformanceBrowserTest : public WebRtcTestBase { WebRtcPerfBrowserTests and WebRtcPerformanceBrowserTests? Umm, no. Rename the old one to WebRtcInternalsPerfBrowserTests and this one to WebRtcStatsPerfBrowserTest or something. You'll have to ask Edward to update the --gtest_filter args in the bot config, so the WebRTC bots pick them up, though.
Replied to a single question: https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:22: On 2016/12/01 15:42:30, phoglund_chrome wrote: > Bytes received/sent is probably one of the more volatile stats you can get out. > You run for 60 seconds and then start looking for stats. What you'll be adding > at that point is > > [10000000003, 10000000013, 10000000050, ...] > > since many bytes have been already been sent. If the call gets established just > a little bit slower or faster it will have a big effect on the average, right? > As you can see on the main tests, they're really noisy (and I think they're > taken off monitoring for that reason: > https://chromeperf.appspot.com/report?sid=edbc402a707f488c03a4e799c1e84662d21...) > > Are there any other stats could look at here? Otherwise, I honestly think it's > better to remove the stabilization period at the start, which benefits bwe and > similar more. Hmm. I don't have any bitrates at my disposal, but how about I run for 60 seconds, do bytesBefore = getStats and run for another 10 seconds and do bytesAfter = getStats, then report the average bytes/second over that 10 second period? This should be fairly stable, I would think.
On 2016/12/01 15:52:03, hbos_chromium wrote: > Replied to a single question: > > https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... > File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): > > https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... > chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:22: > On 2016/12/01 15:42:30, phoglund_chrome wrote: > > Bytes received/sent is probably one of the more volatile stats you can get > out. > > You run for 60 seconds and then start looking for stats. What you'll be adding > > at that point is > > > > [10000000003, 10000000013, 10000000050, ...] > > > > since many bytes have been already been sent. If the call gets established > just > > a little bit slower or faster it will have a big effect on the average, right? > > As you can see on the main tests, they're really noisy (and I think they're > > taken off monitoring for that reason: > > > https://chromeperf.appspot.com/report?sid=edbc402a707f488c03a4e799c1e84662d21...) > > > > Are there any other stats could look at here? Otherwise, I honestly think it's > > better to remove the stabilization period at the start, which benefits bwe and > > similar more. > > Hmm. I don't have any bitrates at my disposal, but how about I run for 60 > seconds, do bytesBefore = getStats and run for another 10 seconds and do > bytesAfter = getStats, then report the average bytes/second over that 10 second > period? This should be fairly stable, I would think. Nice idea, give it a shot!
Description was changed from ========== WebRtcPerformanceBrowserTest added, a perf test using new getStats. Using the promise-based getStats to collect stats, writes stats after 60 seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. Example from other browser test: [2]. This is similar to the WebRtcPerfBrowserTest which uses chrome://webrtc-internals relying on the old callback-based version of getStats, but using the new getStats API (which has a different set of available stats). This performance test only picks up: - browser_tests / audio_[codec] / bytes_sent - browser_tests / audio_[codec] / bytes_received - browser_tests / video_[codec] / bytes_sent - browser_tests / video_[codec] / bytes_received Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ========== to ========== WebRtcStatsPerfBrowserTest added, a perf test using the new getStats. Using the promise-based getStats to collect stats, writes stats after 60+10* seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. E.g. from other browser test: [2]. *(After 60s of ramp-up, performs measurments during a 10s window, to avoid unstable stats due to variations in ramp-up time.) This is similar to the WebRtcPerfBrowserTest - renamed WebRtcInternalsBrowserTest to avoid confusion - which instead uses chrome://webrtc-internals relying on the old callback-based version of getStats. Available stats are different. This performance test only picks up: - browser_tests / audio_[codec] / send_rate - browser_tests / audio_[codec] / receive_rate - browser_tests / video_[codec] / send_rate - browser_tests / video_[codec] / receive_rate Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ==========
PTAL phoglund, hta. Example output: RESULT audio_opus: send_rate= 3065.2 bytes/second RESULT audio_opus: receive_rate= 5084.8 bytes/second And: RESULT video_VP8: send_rate= 218088.5 bytes/second RESULT video_VP8: receive_rate= 218451.5 bytes/second https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:58: class WebRtcPerformanceBrowserTest : public WebRtcTestBase { On 2016/12/01 15:42:30, phoglund_chrome wrote: > WebRtcPerfBrowserTests and WebRtcPerformanceBrowserTests? Umm, no. Rename the > old one to WebRtcInternalsPerfBrowserTests and this one to > WebRtcStatsPerfBrowserTest or something. You'll have to ask Edward to update the > --gtest_filter args in the bot config, so the WebRTC bots pick them up, though. Yeah that's much better. Done.
On 2016/12/02 14:55:46, hbos_chromium wrote: > PTAL phoglund, hta. > > Example output: > > RESULT audio_opus: send_rate= 3065.2 bytes/second > RESULT audio_opus: receive_rate= 5084.8 bytes/second > > And: > > RESULT video_VP8: send_rate= 218088.5 bytes/second > RESULT video_VP8: receive_rate= 218451.5 bytes/second > > https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... > File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): > > https://codereview.chromium.org/2545553003/diff/40001/chrome/browser/media/we... > chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:58: class > WebRtcPerformanceBrowserTest : public WebRtcTestBase { > On 2016/12/01 15:42:30, phoglund_chrome wrote: > > WebRtcPerfBrowserTests and WebRtcPerformanceBrowserTests? Umm, no. Rename the > > old one to WebRtcInternalsPerfBrowserTests and this one to > > WebRtcStatsPerfBrowserTest or something. You'll have to ask Edward to update > the > > --gtest_filter args in the bot config, so the WebRTC bots pick them up, > though. > > Yeah that's much better. Done. yeah. I checked, and the filters are WebRtc* so we don't need to update the bot config.
lgtm
lgtm Always some small comments. https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:25: RTCStatsReportDictionary* report, bool inbound, const char* media_type) { would actually like this better if the "inbound" parameter had the values "inbound-rtp" and "outbound-rtp". Call site is easier to read. You'd have to check the value here for correctness, of course. https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:57: // "chrome://webrtc-internals/"). The stats provided are different. s/different/standards conformant/. Be proud!
The CQ bit was checked by hbos@chromium.org to run a CQ dry run
https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... File chrome/browser/media/webrtc/webrtc_performance_browsertest.cc (right): https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:25: RTCStatsReportDictionary* report, bool inbound, const char* media_type) { On 2016/12/05 09:07:16, hta - Chromium wrote: > would actually like this better if the "inbound" parameter had the values > "inbound-rtp" and "outbound-rtp". Call site is easier to read. You'd have to > check the value here for correctness, of course. Done. https://codereview.chromium.org/2545553003/diff/20001/chrome/browser/media/we... chrome/browser/media/webrtc/webrtc_performance_browsertest.cc:57: // "chrome://webrtc-internals/"). The stats provided are different. On 2016/12/05 09:07:16, hta - Chromium wrote: > s/different/standards conformant/. Be proud! :D
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by hbos@chromium.org
The CQ bit was checked by hbos@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from phoglund@chromium.org, hta@chromium.org Link to the patchset: https://codereview.chromium.org/2545553003/#ps100001 (title: "Addressed nits, rebase, default initialize")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 100001, "attempt_start_ts": 1480934028874510,
"parent_rev": "10b2d4c765749c5d90ec6ce89e1951172052accb", "commit_rev":
"a75ca6a76eaecf54467601c3fa30993f4f842d3f"}
Message was sent while issue was closed.
Description was changed from ========== WebRtcStatsPerfBrowserTest added, a perf test using the new getStats. Using the promise-based getStats to collect stats, writes stats after 60+10* seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. E.g. from other browser test: [2]. *(After 60s of ramp-up, performs measurments during a 10s window, to avoid unstable stats due to variations in ramp-up time.) This is similar to the WebRtcPerfBrowserTest - renamed WebRtcInternalsBrowserTest to avoid confusion - which instead uses chrome://webrtc-internals relying on the old callback-based version of getStats. Available stats are different. This performance test only picks up: - browser_tests / audio_[codec] / send_rate - browser_tests / audio_[codec] / receive_rate - browser_tests / video_[codec] / send_rate - browser_tests / video_[codec] / receive_rate Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ========== to ========== WebRtcStatsPerfBrowserTest added, a perf test using the new getStats. Using the promise-based getStats to collect stats, writes stats after 60+10* seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. E.g. from other browser test: [2]. *(After 60s of ramp-up, performs measurments during a 10s window, to avoid unstable stats due to variations in ramp-up time.) This is similar to the WebRtcPerfBrowserTest - renamed WebRtcInternalsBrowserTest to avoid confusion - which instead uses chrome://webrtc-internals relying on the old callback-based version of getStats. Available stats are different. This performance test only picks up: - browser_tests / audio_[codec] / send_rate - browser_tests / audio_[codec] / receive_rate - browser_tests / video_[codec] / send_rate - browser_tests / video_[codec] / receive_rate Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ==========
Message was sent while issue was closed.
Committed patchset #5 (id:100001)
Message was sent while issue was closed.
Description was changed from ========== WebRtcStatsPerfBrowserTest added, a perf test using the new getStats. Using the promise-based getStats to collect stats, writes stats after 60+10* seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. E.g. from other browser test: [2]. *(After 60s of ramp-up, performs measurments during a 10s window, to avoid unstable stats due to variations in ramp-up time.) This is similar to the WebRtcPerfBrowserTest - renamed WebRtcInternalsBrowserTest to avoid confusion - which instead uses chrome://webrtc-internals relying on the old callback-based version of getStats. Available stats are different. This performance test only picks up: - browser_tests / audio_[codec] / send_rate - browser_tests / audio_[codec] / receive_rate - browser_tests / video_[codec] / send_rate - browser_tests / video_[codec] / receive_rate Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 ========== to ========== WebRtcStatsPerfBrowserTest added, a perf test using the new getStats. Using the promise-based getStats to collect stats, writes stats after 60+10* seconds of audio and video calling. These will be picked up by the Chrome Performance Dashboard[1]. E.g. from other browser test: [2]. *(After 60s of ramp-up, performs measurments during a 10s window, to avoid unstable stats due to variations in ramp-up time.) This is similar to the WebRtcPerfBrowserTest - renamed WebRtcInternalsBrowserTest to avoid confusion - which instead uses chrome://webrtc-internals relying on the old callback-based version of getStats. Available stats are different. This performance test only picks up: - browser_tests / audio_[codec] / send_rate - browser_tests / audio_[codec] / receive_rate - browser_tests / video_[codec] / send_rate - browser_tests / video_[codec] / receive_rate Based on "RTC[In/Out]boundRTPStreamStats.bytes_[sent/received]" values [3][4]. For audio codecs: opus, ISAC, G722, PCMU, PCMA. And video codecs: VP8, VP9, H264. More stats can be picked up in follow-up CLs, but the new getStats API has a limited number of stats available. [1] https://chromeperf.appspot.com/ [2] https://chromeperf.appspot.com/report?sid=4a337ff35047d3a12a0b6d05fa1bf95e001... [3] https://w3c.github.io/webrtc-stats/#dom-rtcoutboundrtpstreamstats-bytessent [4] https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-bytesreceived BUG=670306, 627816 Committed: https://crrev.com/32bafc424946864c744ecfc0cbd83f6d5c18852b Cr-Commit-Position: refs/heads/master@{#436260} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/32bafc424946864c744ecfc0cbd83f6d5c18852b Cr-Commit-Position: refs/heads/master@{#436260} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
