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}
This fixes compilation errors as the following:
error: constructor must explicitly initialize the const member
BUG=506663
R=aluebs@webrtc.org, tommi@webrtc.org
Signed-off-by: Eduardo Lima (Etrunko) <eduardo.lima@intel.com>
Review URL: https://codereview.webrtc.org/1222233002
Cr-Commit-Position: refs/heads/master@{#9538}
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}
Clang warns if there are missing braces around a subobject
initializer. The most common idiom that triggers this is:
STRUCT s = {0};
if the first field of STRUCT is itself a struct. This can
be more simply written as:
STRUCT s = {};
which also prevents the warning from firing.
Other instances of the warning have been fixed by adding
braces where appropriate.
BUG=505297
TBR=jiayl@webrtc.org
Review URL: https://codereview.webrtc.org/1216353002
Cr-Commit-Position: refs/heads/master@{#9529}
Prevents OOB reads on truncated FU-A NAL units, StapA headers and past
truncation just after StapA headers.
BUG=webrtc:4771
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/1218023003
Cr-Commit-Position: refs/heads/master@{#9522}
in the ACMDump. The ACMDump interface itself is not updated, so there
is no way (yet) to actually write the configuration fields.
BUG=
Review URL: https://codereview.webrtc.org/1202833003
Cr-Commit-Position: refs/heads/master@{#9519}
Sudden platform system delay jumps can hurt AEC and we have no stats that monitor these jumps. How often do they occur, and when they are reported are they accurate?
This CL logs all jumps in both the reported and actual delay.
The histogram has been tested with a chromium build where a fake jump of 200 ms was applied after 5 seconds and it was registered correctly in chrome://histograms
BUG=488124
R=henrik.lundin@webrtc.org, peah@webrtc.org
Review URL: https://codereview.webrtc.org/1213733004.
Cr-Commit-Position: refs/heads/master@{#9513}
