WebRTC Testbed - Cronologia

SMascolo: /* TCP Settings */

2016-05-31T16:37:14Z

‎TCP Settings

2016-05-31T16:36:34Z

‎Video Settings

2016-05-31T16:36:27Z

‎Video Settings

2016-05-31T16:34:54Z

‎Web Server Settings

2016-05-31T16:34:37Z

‎Google Congestion Control Settings

2016-05-31T16:33:55Z

‎Google Congestion Control Settings

2016-05-31T16:33:16Z

‎Google Congestion Control Settings

2016-05-31T16:32:57Z

‎Google Congestion Control Settings

2016-05-31T16:32:08Z

‎Google Congestion Control Settings

2016-05-31T16:31:56Z

‎Google Congestion Control Settings

@@ Riga 61: / Riga 61: @@
 <nowiki># echo cubic > /proc/sys/net/ipv4/tcp_congestion_control</nowiki>
-In order to run the TCP flows iPerf-like application can be used:
+In order to run the TCP flows IPerf-like application can be used:
 * https://iperf.fr/

@@ Riga 50: / Riga 50: @@
 * https://people.xiph.org/~thdavies/x264_streams/FourPeople_1280x720_30/
-In order to fed Chromium browser with this video sequence, different approaches can be used.
+In order to fed Chromium browser with this video sequence, different approaches can be used:
 #The Linux kernel module [https://github.com/umlaeute/v4l2loopback v4l2loopback] can be used to create a virtual webcam device which cyclically repeats the video test sequence.
 #The  video test sequence can be directly fed to Chromium using the flag --use-file-for-fake-video-capture. Other useful flags for testing are available [https://webrtc.org/testing/ here].

@@ Riga 50: / Riga 50: @@
 * https://people.xiph.org/~thdavies/x264_streams/FourPeople_1280x720_30/
-In order to fed Chromium browser with this video sequence difference approaches can be used.
+In order to fed Chromium browser with this video sequence, different approaches can be used.
 #The Linux kernel module [https://github.com/umlaeute/v4l2loopback v4l2loopback] can be used to create a virtual webcam device which cyclically repeats the video test sequence.
 #The  video test sequence can be directly fed to Chromium using the flag --use-file-for-fake-video-capture. Other useful flags for testing are available [https://webrtc.org/testing/ here].

@@ Riga 41: / Riga 41: @@
 == Web Server Settings ==
-In order to establish WebRTC calls among the Chromium browsers running on Nodes of Figure 1, a Web server is required. In particular the Web server provides the HTML pages that handles the signaling between the peers using the WebRTC JavaScript API.
+In order to establish WebRTC calls among the Chromium browsers which run on Nodes of Figure 1, a Web server is required. In particular the Web server provides the HTML pages that handles the signaling between the peers using the WebRTC JavaScript API.
 To this purpose we have used the [https://appr.tc video chat demo app] which can be installed locally following this guide:

@@ Riga 38: / Riga 38: @@
 # Using the traces from the Chromium source code after re-compilation. For example video bitrate can be extracted [https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/rtp_rtcp/source/rtp_sender.cc&l=225 here].
 # Using the Javascript getstats() API. An example is provided [https://github.com/muaz-khan/getStats here]. This approach does not require re-compilation.
-# Using linux tool. For example ''tcpdump'' to measure the sending bitrate, ''ping'' to measure the RTT. [https://webrtc.org/testing/wireshark/#capturing-rtp-streams This guideline] instead explains how to use ''wireshark'' to capture and analyze the RTP stream.
+# Using linux tool. For example ''tcpdump'' to measure the sending bitrate, ''ping'' to measure the RTT. [https://webrtc.org/testing/wireshark/#capturing-rtp-streams This guideline] explains how to use ''wireshark'' to capture and analyze the RTP stream.
 == Web Server Settings ==

@@ Riga 36: / Riga 36: @@
 Relevant metrics, such as sending bitrate, RTT, packets losses, can be measured by employing different approaches. Here we cite some:
-# Extracting the matrics in the form of traces from the Chromium source code after re-compilation. For example video bitrate can be extracted [https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/rtp_rtcp/source/rtp_sender.cc&l=225 here].
+# Extracting the metrics in the form of traces from the Chromium source code after re-compilation. For example video bitrate can be extracted [https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/rtp_rtcp/source/rtp_sender.cc&l=225 here].
 # Using the Javascript getstats() API. An example is provided [https://github.com/muaz-khan/getStats here]. This approach does not require re-compilation.
 # Using linux tool. For example ''tcpdump'' to measure the sending bitrate, ''ping'' to measure the RTT. [https://webrtc.org/testing/wireshark/#capturing-rtp-streams This guideline] instead explains how to use ''wireshark'' to capture and analyze the RTP stream.

@@ Riga 28: / Riga 28: @@
 : 1. [https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/modules/remote_bitrate_estimator/ Remote Bitrate Estimator]
 :: This directory contains the delay-based controller implementation in the form of three main classes:
-:: 1. Over Use Detector: (overuse_estimator.cc) which estimates the one-way delay variation between the incoming packets with a Kalman filter;
+:: 1. Over Use Detector: (overuse_estimator.cc) which estimates the one way delay variation between the incoming packets with a Kalman filter;
 :: 2. Over Use Estimator: (overuse_detector.cc) which compares the one way delay variation with a threshold and generates a signal that reports the status of the network (over-used, normal, under-used);
 :: 3. Rate Control: (aimd_rate_control.cc) which uses this signal to drive a finite state machine that computes the sending bitrate.