Reason for revert:
Breaks Chromium FYI content_browsertest on all platforms. The testcase that fails is WebRtcAecDumpBrowserTest.CallWithAecDump.
https://build.chromium.org/p/chromium.webrtc.fyi/builders/Linux/builds/19388
Sample output:
[ RUN ] WebRtcAecDumpBrowserTest.CallWithAecDump
Xlib: extension "RANDR" missing on display ":9".
[4:14:0722/211548:1282124453:WARNING:webrtcvoiceengine.cc(472)] Unexpected codec: ISAC/48000/1 (105)
[4:14:0722/211548:1282124593:WARNING:webrtcvoiceengine.cc(472)] Unexpected codec: PCMU/8000/2 (110)
[4:14:0722/211548:1282124700:WARNING:webrtcvoiceengine.cc(472)] Unexpected codec: PCMA/8000/2 (118)
[4:14:0722/211548:1282124815:WARNING:webrtcvoiceengine.cc(472)] Unexpected codec: G722/8000/2 (119)
[19745:19745:0722/211548:1282133667:INFO:CONSOLE(64)] "Looking at video in element remote-view-1", source: http://127.0.0.1:48819/media/webrtc_test_utilities.js (64)
[19745:19745:0722/211548:1282136892:INFO:CONSOLE(64)] "Looking at video in element remote-view-2", source: http://127.0.0.1:48819/media/webrtc_test_utilities.js (64)
../../content/test/webrtc_content_browsertest_base.cc:62: Failure
Value of: ExecuteScriptAndExtractString( shell()->web_contents(), javascript, &result)
Actual: false
Expected: true
Failed to execute javascript call({video: true, audio: true});.
From javascript: (nothing)
When executing 'call({video: true, audio: true});'
../../content/test/webrtc_content_browsertest_base.cc:75: Failure
Failed
../../content/browser/media/webrtc_aecdump_browsertest.cc:26: Failure
Expected: (base::kNullProcessId) != (*id), actual: 0 vs 0
../../content/browser/media/webrtc_aecdump_browsertest.cc:95: Failure
Value of: GetRenderProcessHostId(&render_process_id)
Actual: false
Expected: true
../../content/browser/media/webrtc_aecdump_browsertest.cc:99: Failure
Value of: base::PathExists(dump_file)
Actual: false
Expected: true
../../content/browser/media/webrtc_aecdump_browsertest.cc:101: Failure
Value of: base::GetFileSize(dump_file, &file_size)
Actual: false
Expected: true
../../content/browser/media/webrtc_aecdump_browsertest.cc:102: Failure
Expected: (file_size) > (0), actual: 0 vs 0
[ FAILED ] WebRtcAecDumpBrowserTest.CallWithAecDump, where TypeParam = and GetParam() = (361 ms)
Original issue's description:
> Allow more than 2 input channels in AudioProcessing.
>
> The number of output channels is constrained to be equal to either 1 or the
> number of input channels.
>
> R=aluebs@webrtc.org, andrew@webrtc.org, pbos@webrtc.org
>
> Committed: c204754b7aTBR=andrew@webrtc.org,aluebs@webrtc.org,ajm@chromium.org,pbos@chromium.org,pbos@webrtc.org,mgraczyk@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.webrtc.org/1253573005
Cr-Commit-Position: refs/heads/master@{#9621}
These are mostly trivial changes and are separated out just to reduce the
diff on that change to the minimum possible.
Note explanatory comments on patch set 1.
BUG=none
TEST=none
Review URL: https://codereview.webrtc.org/1235643003
Cr-Commit-Position: refs/heads/master@{#9617}
Android has not yet finalized its libc++ build. Allow compilation with
stlport by removing several C++11 library usages.
BUG=427718,487341,webrtc:4866
R=andrew@webrtc.org
Review URL: https://codereview.webrtc.org/1250663007 .
Patch from Jared Duke <jdduke@chromium.org>.
Cr-Commit-Position: refs/heads/master@{#9616}
Supports:
- bwe_plot.sh
---- Histogram plots
---- Baseline histograms
---- Vertical error lines
---- Dashed horizontal lines
---- Different colors for different algorithms
---- Legends read as input
---- Extra horizontal space in case there are TCP flows plotted
---- Multiple windows
---- Auto vertical scale, except for latency plots which are kept constant for all plots
- plot_dynamics.py
---- Dynamic plots
---- Different colors for different flows and algorithms
---- Dashed line plot for available capacity
---- Throughput, latency and loss on separated boxes
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1237903003 .
Cr-Commit-Position: refs/heads/master@{#9614}
In #9243 we added some thread_checker. But it shouldn't be added into PlayoutDevices() and RecordingDevices(), since these two will be invoked from RecThread and PlayoutThread too, other than the main thread.
BUG=webrtc:4852
TEST=voe_cmd_test
R=henrika@webrtc.org
Review URL: https://codereview.webrtc.org/1249573002 .
Cr-Commit-Position: refs/heads/master@{#9605}
Using a right-sided (absolute value), truncated gaussian distribution originally with zero mean.
Currently truncated at x = 3 * std_dev.
Added expected value computation.
Modified jitter unittests accordingly.
BUG=webrtc:4848
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1237303002 .
Cr-Commit-Position: refs/heads/master@{#9587}
---- Dynamic receiving rate.
---- Dynamic packet-loss.
---- Dynamic objective function.
---- Dynamic available capacity.
---- Dynamic available capacity per flow.
---- Average delay Histogram with standard deviation or 5th/95th percentiles.
---- Average bitrate Histogram with error bars.
---- Optimal average bitrate dashed line.
---- Average packet-loss Histogram.
---- Total objective function Histogram.
Added media Pause/Resume methods to Video and TcpSender.
Modified LinkedSet: computing GlobalPacketLossRatio even if packet's sequence_number overflows.
Added small randomization to frame send times, modified bwe_test_framework_unittest accordingly.
Taking offset time into account for plotting.
Added nada_unittests.
Added bwe_unittests.
Added a RateCounter to BweReceiver (replaced ReceivingRate)
Added LossAccount.
Fixed NadaBweReceiver issue: using sender_timestamp instead of creation_time.
Fixed memory leaks.
Fixed int division rounding issues.
Supporting plots on bandwidth Estimators:
Logging received packet information on on SubClassesBweReceiver::ReceivePacket
Updating RateCounter, updating packet loss account and relieving LinkedSet when necessary.
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1202253003 .
Cr-Commit-Position: refs/heads/master@{#9585}
This patch tests separate iSAC encoder and decoder in more cases (32
kHz in addition to 16 kHz, and 30 ms adaptive and 60 ms nonadaptive).
In order to handle 32 kHz adaptive, the decoder needs to be told of
the encoder's sample rate (16 kHz worked already because that's the
default). And since we can't set the encoder's frame size without also
setting its bit rate, we need a way to set the decoder's bit rate as
well.
It turned out to be way too messy to continue verifying that the
bandwidth estimator does something reasonable in all these cases,
because it seems it doesn't. So the GetSetBandwidthInfo is now just
responsible for ensuring that split encoder/decoder behaves the same
as conjoined encoder/decoder; the job of verifying that the bandwidth
estimator does its job properly falls on some other test (that doesn't
exist yet).
Review URL: https://codereview.webrtc.org/1225093005
Cr-Commit-Position: refs/heads/master@{#9583}
Also fixed an arithmetic issue where a 0 0 3 at the end of the rbsp would include the 3 (that's not a legal bitstream anyway, so it probably wasn't a real bug, but it was incorrect).
This maintains the underflow fix from an earlier CL (https://codereview.webrtc.org/1219493004/). The overflow fix is virtually impossible to hit (hence no unit tests), but is there for strict correctness.
BUG=
Review URL: https://codereview.webrtc.org/1226203002
Cr-Commit-Position: refs/heads/master@{#9581}
Adds a class used to classify whether packet loss events are a single packet or multiple packets as well as how many packets have been lost. Also exposes a new function in the RtpRtcp interface to retrieve these statistics.
BUG=
Review URL: https://codereview.webrtc.org/1198853004
Cr-Commit-Position: refs/heads/master@{#9568}
- New option for computing variance that is more adaptive with lower complexity.
- Fixed related off-by-one errors.
- Added intelligibility unittests.
- Do not enhance if experiencing variance underflow.
R=andrew@webrtc.org, henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1207353002 .
Cr-Commit-Position: refs/heads/master@{#9567}
This reduces the risk of getting a small initial estimate when doing combined a/v BWE, and the audio stream is received earlier than the video stream.
In addition a check is added to make sure a probe can't reduce the BWE.
R=pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1219303002 .
Cr-Commit-Position: refs/heads/master@{#9560}
Note: Regarding the ICMP6_CLOSE_FUNC variable in winping.cc,
Icmp6CloseHandle does not exist, and IcmpCloseHandle is the correct way
to close an IPv6 handle. Therefore the existing code is correct to use
close_ on both types of connections and this variable is unnecessary.
BUG=505319
Review URL: https://codereview.webrtc.org/1231653003
Cr-Commit-Position: refs/heads/master@{#9555}
To be used in tests that depend on specific field-trial settings without
overwriting the command-line flag for overriding field trials.
BUG=webrtc:4820
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1227653002
Cr-Commit-Position: refs/heads/master@{#9547}
These payload types aren't directly connected to any payload type, and
the payload type still has to be negotiated externally. As such these
constants are just a source of confusion.
BUG=
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1215603003
Cr-Commit-Position: refs/heads/master@{#9546}
This improves self-fairness and competing for resources with TCP flows.
BUG=4711
Review URL: https://codereview.webrtc.org/1151603008
Cr-Commit-Position: refs/heads/master@{#9545}
We have two histograms today that trigger on large jumps in either platform reported stream delays (WebRTC.Audio.PlatformReportedStreamDelayJump) or the system delay in the AEC (WebRTC.Audio.AecSystemDelayJump). The latter is the internal buffer size in the AEC.
The sizes of such jumps are of relevance since it can harm the AEC and even put it in a complete failure state. It is hard, not to say impossible, to tell how frequent it is.
Therefore, two complementary histograms are added; number of jumps in each metric.
This way we get a quick way to determine how often a jump occurs in general and also how frequent it is within a call.
This is solved by adding a counter for each metric.
The counter is activated either upon an event trigger or if we know for sure when the AEC is running.
Unfortunately, we can't rely on the destructor at the end of a call so we add a public API for the user to take on the action of calling it at the end of a call.
Tested locally by building ToT chromium including changes and three triggered jumps (200, 50 and 60 ms).
The stats picked up the 60 and 200 ms jumps as expected.
BUG=488124
R=asapersson@webrtc.org, pbos@webrtc.org
Review URL: https://codereview.webrtc.org/1229443003.
Cr-Commit-Position: refs/heads/master@{#9544}
Bugs found by manual inspection of code, not by fuzzing or packet
replays. At least one of them confirmed by local fuzzing.
BUG=chromium:496094, webrtc:4771
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1182793002
Cr-Commit-Position: refs/heads/master@{#9542}
The UMA histograms WebRTC.Audio.AecSystemDelayJump and WebRTC.Audio.PlatformReportedStreamDelayJump triggers if the jump is larger than kMinDiffDelayMs.
Especially WebRTC.Audio.AecSystemDelayJump is sensitive around 50 ms differences, since the granularity is 4 ms and we can get a significant amount of hits at 52 ms.
Therefore, a change to 60 ms can make the logging more robust. The effect of not logging jumps in the interval 50-60 ms is of minor importance since they are not likely to affect the AEC performance. It's when we get values from ~100 ms and above that we should be worried.
Tested with a local ToT Chromium build where 52, 64 and 200 ms jumps were forced.
BUG=488124
TBR=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1208313003.
Cr-Commit-Position: refs/heads/master@{#9540}
They make it possible to send bandwidth estimation info from decoder
to encoder even if they are separate objects (which we want them to be
because multithreading).
R=henrik.lundin@webrtc.org
Review URL: https://codereview.webrtc.org/1208923002.
Cr-Commit-Position: refs/heads/master@{#9535}
Using random "garbage" bytes makes testing harder for no good reason.
Any deterministic sequence would do, but we choose all zeros because
it's simple.
Review URL: https://codereview.webrtc.org/1211243014
Cr-Commit-Position: refs/heads/master@{#9532}
We use this Config struct for enabling/disabling the delay agnostic
AEC. This change renames it to DelayAgnostic for readability reasons.
NOTE: The logic is reversed in this CL. The old ReportedDelay config
turned DA-AEC off, while the new DelayAgnostic turns it on.
The old Config is kept in parallel with the new during a transition
period. This is to avoid problems with API breakages. During this
period, ReportedDelay is disabled or DelayAgnostic is enabled, DA-AEC
is engaged in APM.
BUG=webrtc:4651
R=bjornv@webrtc.org, tommi@webrtc.org
Review URL: https://codereview.webrtc.org/1211053006
Cr-Commit-Position: refs/heads/master@{#9531}
