I used a command like this to update the paths:
perl -pi -e "s/webrtc\/base/webrtc\/rtc_base/g" `find webrtc/rtc_base -name "*.cc" -o -name "*.h"`
The only manual edit is to add an include of webrtc/rtc_base/checks.h in
webrtc/modules/audio_device/android/opensles_common.h, which likely
was needed due to changed include paths due to 'git cl format'.
BUG=webrtc:7634
NOTRY=True
NOPRESUBMIT=True
Review-Url: https://codereview.webrtc.org/2969653002
Cr-Commit-Position: refs/heads/master@{#18871}
It's the faster, less strict cousin of checked_cast.
BUG=none
Review-Url: https://codereview.webrtc.org/2714063002
Cr-Commit-Position: refs/heads/master@{#16958}
This means that smaller probe packets will be allowed at lower bitrates.
BUG=webrtc:7043
Review-Url: https://codereview.webrtc.org/2650393002
Cr-Commit-Position: refs/heads/master@{#16317}
Instead of having to specify a bitrate and how many packets to use,
the BitrateProber will now use the bitrate to calculate how many
bytes it will use to probe that bitrate instead.
For now, |kMinProbeDurationMs| is set to 15 ms which means that probing
at 1900 kbps will result in 1900/8*0.015 = 3.5 kB used. Since we can
expect packets to be smaller at the beginning of a stream (500 to 700
bytes) this will result in 7 to 5 packets sent for that bitrate, and
should work very similar to how the current initial probing works.
A minimum of 5 packets are always sent.
BUG=webrtc:6822
Review-Url: https://codereview.webrtc.org/2609113003
Cr-Commit-Position: refs/heads/master@{#15899}
Previously ProbeController would overflow int when calculating
min_bitrate_to_probe_further_bps and when probing bitrate is
above 17 Mbps. The problem was introduced in
https://codereview.webrtc.org/2504023002. Fixed ProbeController to use
int64_t internally for bitrate calculations.
BUG=6332
Review-Url: https://codereview.webrtc.org/2574533002
Cr-Commit-Position: refs/heads/master@{#15642}
https://codereview.webrtc.org/2504023002 broke exponential probing.
After that change ProbeController stops exponential probes prematurely:
it goes to kProbingComplete state if SetEstimatedBitrate() is called
with bitrate lower than min_bitrate_to_probe_further_bps_, which always
happens with the first pair of probes. As result it wasn't sending
repeated probes as it should. This change fixes that issue by moving
probe expieration logic to ProbeContoller::Process(). This also ensures
that the controller goes to kProbingComplete state as soon as probing
timeout expired, without waiting for the next SetEstimatedBitrate()
call.
BUG=669421
Review-Url: https://codereview.webrtc.org/2546613003
Cr-Commit-Position: refs/heads/master@{#15392}
Now ProbeController can send periodic bandwidth probes when in
application-limited region. This will allow to maintain correct
bottleneck bandwidth estimate, even not all bandwidth is being used.
The feature is not enabled by default, but can be enabled with a flag.
Interval between probes is currently set to 5 seconds.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504023002
Cr-Commit-Position: refs/heads/master@{#15279}
Previously ProbeController was starting probing as soon as SetBitrates()
is called. As result these probes would often timeout while connection
is being established. Now ProbeController receives notifications about
network route changes. This allows to start probing only when transport
is connected. This also makes it possible to restart probing whenever
transport route changes (will be done in a separate change).
BUG=webrtc:6332
R=honghaiz@webrtc.org, philipel@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2458863002 .
Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
Cr-Original-Commit-Position: refs/heads/master@{#15094}
Cr-Commit-Position: refs/heads/master@{#15204}
Reason for revert:
It broke downstream test.
Original issue's description:
> Start probes only after network is connected.
>
> Previously ProbeController was starting probing as soon as SetBitrates()
> is called. As result these probes would often timeout while connection
> is being established. Now ProbeController receives notifications about
> network route changes. This allows to start probing only when transport
> is connected. This also makes it possible to restart probing whenever
> transport route changes (will be done in a separate change).
>
> BUG=webrtc:6332
>
> Committed: https://crrev.com/5c99c76255ee7bface3c742c25fb5617748ac86e
> Cr-Commit-Position: refs/heads/master@{#15094}
TBR=philipel@webrtc.org,stefan@webrtc.org,sergeyu@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2504783002
Cr-Commit-Position: refs/heads/master@{#15098}
Previously ProbeController was starting probing as soon as SetBitrates()
is called. As result these probes would often timeout while connection
is being established. Now ProbeController receives notifications about
network route changes. This allows to start probing only when transport
is connected. This also makes it possible to restart probing whenever
transport route changes (will be done in a separate change).
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2458863002
Cr-Commit-Position: refs/heads/master@{#15094}
Previously probing bitrate was capped at 10Mbps, which is too low for some
application. Now ProbeContoller limits max probing rate to max allowed
bitrate, which can be specified by the application.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2430133005
Cr-Commit-Position: refs/heads/master@{#14927}
