The test was heavily dependent on wall clock timing, so it ended up
being disabled in some build configurations. This CL switches it to use
a fake clock instead.
BUG=webrtc:5947
Review-Url: https://codereview.webrtc.org/2392613003
Cr-Commit-Position: refs/heads/master@{#14507}
NetEq already uses SdpAudioFormat internally; this CL adds an
AudioCodingModule::RegisterReceiveCodec overload that accepts
SdpAudioFormat, and propagates it through AcmReceiver into NetEq.
The intention is to get rid of the other ways to specify decoders and
always use SdpAudioFormat. (And eventually to do the same for encoders
too.)
NOTRY=true
BUG=5801
Review-Url: https://codereview.webrtc.org/2365653004
Cr-Commit-Position: refs/heads/master@{#14506}
This is a simple application limited region detector that is quite conservative
at the moment. We detect as being application-limited if we see sending rate
as less than 30% of the estimated bandwidth over 500 ms. The moment we detect
a single burst above 30% over a 100 ms period, we consider ourselves network
limited.
This class is currently not used. A follow up CL will leverage this to enable probing.
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2340763004
Cr-Commit-Position: refs/heads/master@{#14505}
Currently, BitrateProber does not scale higher than 2 Mbps to 6 Mbps. The actual
number is dependent on the size of the last packet. If a packet of around 250
bytes is used for probing, it fails above 2 Mbps.
BitrateProber now provides a recommendation on probe size instead of a
packet size. PacedSender utilizes this to decide on the number of packets
per probe. This enables BitrateProber to scale up-to higher bitrates.
Tests with chromoting show it stalls at about 10 Mbps (perhaps due to the
limitation on the simulation pipeline to deliver packets).
BUG=webrtc:6332
Review-Url: https://codereview.webrtc.org/2347023002
Cr-Commit-Position: refs/heads/master@{#14503}
Also update gyp dependency from rtc_base to rtc_base_approved.
BUG=None.
Review-Url: https://codereview.webrtc.org/2368203002
Cr-Commit-Position: refs/heads/master@{#14497}
This CL introduces changes that clearly demarcate
where we disable Unequal Protection in the FEC.
No functional changes are expected.
BUG=webrtc:5654
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2314743002 .
Cr-Commit-Position: refs/heads/master@{#14496}
Addresses a regression in the NetEq performance test.
# Added NOTRY due to android_arm64_rel being swamped.
NOTRY=True
BUG=chromium:651426
Review-Url: https://codereview.webrtc.org/2383723002
Cr-Commit-Position: refs/heads/master@{#14495}
RunPlayoutAndRecordingInFullDuplex fails sometimes on Android swarming
bots, presumably because the timing is hardware dependent.
This test ensures that audio starts pumping. The exact performance is
not that important.
R=kjellander@webrtc.org, henrika@webrtc.org
BUG=webrtc:6464
NOTRY=True
Review-Url: https://codereview.webrtc.org/2391563002
Cr-Commit-Position: refs/heads/master@{#14492}
- Change some member functions to be private. These were only
called by other private member functions.
- Replace DeleteMediaPackets() with direct calls to
media_packets_.clear()
- Rename GetFecPacketsAsRed to GetUlpfecPacketsAsRed.
No functional changes are intended by this CL.
BUG=webrtc:5654
R=stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2305793003 .
Cr-Commit-Position: refs/heads/master@{#14491}
After https://codereview.webrtc.org/2386573002 changed where resolution
changes are handled, a few VideoSendStreamTests became flaky. They were
waiting for an InitEncode call they triggered, but sometimes were
getting one triggered by the resolution change when the first frame was
generated.
The fix was to make the tests wait for two InitEncode calls first -
one when the stream is created, and the second when the first frame was
encoded.
BUG=webrtc:6467, webrtc:6371
R=perkj@webrtc.org, stefan@webrtc.org
Review URL: https://codereview.webrtc.org/2387293002 .
Cr-Commit-Position: refs/heads/master@{#14490}
- Place all member function definitions between test fixture
declaration and unit tests.
- Rename GenerateFrame -> PacketizeFrame.
No functional changes are intended by this CL.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2275303003
Cr-Commit-Position: refs/heads/master@{#14488}
Helper class for FlexFEC unit tests to come.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2282473002
Cr-Commit-Position: refs/heads/master@{#14487}
The RtcEventLog headers need to be accessible from any place which needs
logging, and the implementation needs access to data structures that are
logged.
After a discussion in the code review, we all agreed to move the RtcEventLog implementation into its own top level directory - which I called "logging/" in expectation that other types of logging may have similar requirements. The directory contains two main build targets - "rtc_event_log_api", which is just rtc_event_log.h, that has no external dependencies and can be used from anywhere, and "rtc_event_log_impl" which contains the rest of the implementation and has many dependencies (more in the future).
The "api" target can be referenced from anywhere, while the "impl" target is only needed at the place of instantiation (currently Call, soon to be moved to PeerConnection by https://codereview.webrtc.org/2353033005/).
This change allows using RtcEventLog in the p2p/ directory, so that we
can log STUN pings and ICE state transitions.
BUG=webrtc:6393
R=kjellander@webrtc.org, kwiberg@webrtc.org, solenberg@webrtc.org, stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2380683005 .
Cr-Commit-Position: refs/heads/master@{#14485}
hbos and hta are already OWNERS of webrtc/stats/ and of rtcstats* files
(per-file rtcstats*=) in webrtc/api/. When the webrtc/api/stats/ folder
was created we forgot to add this OWNERS file (per-file OWNERS does not
apply to subfolders apparently).
BUG=chromium:627816
NOTRY=True
Review-Url: https://codereview.webrtc.org/2392633002
Cr-Commit-Position: refs/heads/master@{#14482}
This DCHECK is triggered by org.webrtc.PeerConnectionTest#testTrackRemoval.
BUG=webrtc:6465
Review-Url: https://codereview.webrtc.org/2389703002
Cr-Commit-Position: refs/heads/master@{#14481}
Changing this constant has been empirically proven to solve the issue.
BUG=webrtc:6455,b/31827852
Review-Url: https://codereview.webrtc.org/2382733006
Cr-Commit-Position: refs/heads/master@{#14479}
Main changes:
- Split out general functionality from UlpfecPacketGenerator
into a new class AugmentedPacketGenerator. This will allow
for the addition of a FlexfecPacketGenerator that inherits
from AugmentedPacketGenerator.
- Rename RawRtpPacket to AugmentedPacket. This name is more
reflective of its purpose, i.e., an FEC packet with an
additional WebRtcRTPHeader.
- Return std::unique_ptr's instead of raw pointers.
Minor changes:
- Update names, based on RawRtpPacket -> AugmentedPacket name
change, in FEC unit tests.
- Rename |generator_| to |packet_generator_|, in FEC unit tests.
- Change some int's to size_t's in the packet generator classes.
- Use std::unique_ptr in ProducerFec unittest.
No functionality or performance changes are expected
due to this CL.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2271273004
Cr-Commit-Position: refs/heads/master@{#14477}
- Change some types to size_t.
- Update parameter ordering.
- Run 'git cl format'
- Moved 'using declarations' into unnamed namespaces.
- Removed "::webrtc::" prefix from some using declarations.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2273353002
Cr-Commit-Position: refs/heads/master@{#14475}
The former is always defined (by webrtc/base/checks.h) to either 0 or
1, whereas the latter isn't necessarily defined.
NOTRY=true
BUG=webrtc:6451
Review-Url: https://codereview.webrtc.org/2384693002
Cr-Commit-Position: refs/heads/master@{#14474}
Also, change order of definition in fec_test_helper.{h,cc}.
This CL should have no implications on functionality. It is in preparation
for a FlexfecPacketGenerator class, which will be used in the FlexFEC
unit tests.
R=danilchap@webrtc.org
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2276473002
Cr-Commit-Position: refs/heads/master@{#14471}
Add classes that can read and finalize FlexFEC headers.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2269903002
Cr-Commit-Position: refs/heads/master@{#14469}
The implementation is borrowed from Chromium.
Also change use of raw pointers in VideoSendStreamImpl to use WeakPtr<>
BUG= webrtc:6289
Review-Url: https://codereview.webrtc.org/2367853002
Cr-Commit-Position: refs/heads/master@{#14468}
The original landed cl is in patchset 1.
The following patchset fix VideoQualityTest as well as fix the case where max_bitrate is set in the SendParams. A unit test is added for that as well.
Original cl description:
Let ViEEncoder handle resolution changes.
This cl move codec reconfiguration due to video frame size changes from WebRtcVideoSendStream to ViEEncoder.
With this change, many variables in WebRtcVideoSendStream no longer need to be locked.
BUG=webrtc:5687, webrtc:6371, webrtc:5332
Review-Url: https://codereview.webrtc.org/2386573002
Cr-Commit-Position: refs/heads/master@{#14467}
The Connection class will now blindly forward SignalReadyToSend, and
P2PTransportChannel will decide whether to forward it further (which
it was already doing).
BUG=webrtc:6448
Review-Url: https://codereview.webrtc.org/2374183005
Cr-Commit-Position: refs/heads/master@{#14462}
This means the DTLS handshake can make progress while the SDP answer
containing the fingerprint is still in transit. If the signaling path
if significantly slower than the media path, this can have a moderate
impact on call setup time.
Of course, until the fingerprint is verified no media can be sent. Any
attempted write will result in SR_BLOCK.
This essentially fulfills the requirements of RFC 4572, Section 6.2:
Note that when the offer/answer model is being used, it is possible
for a media connection to outrace the answer back to the offerer.
Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass'
role, it MUST (as specified in RFC 4145 [2]) begin listening for an
incoming connection as soon as it sends its offer. However, it MUST
NOT assume that the data transmitted over the TLS connection is valid
until it has received a matching fingerprint in an SDP answer. If
the fingerprint, once it arrives, does not match the client's
certificate, the server endpoint MUST terminate the media connection
with a bad_certificate error, as stated in the previous paragraph.
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2163683003
Cr-Commit-Position: refs/heads/master@{#14461}
