- Rename GenerateFec -> EncodeFec in ForwardErrorCorrection. This naming
is more consistent with DecodeFec.
- Add appropriate using directives, to reduce clutter in tests.
- Move ConstructMediaPackets to fec_test_helper.{h,cc}. This will help
future tests of ULPFEC/FlexFEC header formatters.
- Generalize tests in rtp_fec_unittest.cc to typed tests. This will help
testing ForwardErrorCorrection with both ULPFEC and FlexFEC.
This CL should not impact functionality or performance.
BUG=webrtc:5654
Review-Url: https://codereview.webrtc.org/2267393002
Cr-Commit-Position: refs/heads/master@{#14314}
Before this CL, the IntelligibilityEnhancer introduced a processing delay to the lower band, without compensating for it in the higher bands. This CL corrects this.
BUG=b/30780909
R=henrik.lundin@webrtc.org, peah@webrtc.org
Review URL: https://codereview.webrtc.org/2320833002 .
Cr-Commit-Position: refs/heads/master@{#14311}
These are no longer used in Chromium, so deleting them will not break any
third party project.
BUG=chromium:627816
NOTRY=True
Review-Url: https://codereview.webrtc.org/2352993002
Cr-Commit-Position: refs/heads/master@{#14309}
Verifies that NetEq doesn't enter muted state when CNG mode is active
and the packet stream is suspended for a long time.
BUG=webrtc:5608
Review-Url: https://codereview.webrtc.org/2335343011
Cr-Commit-Position: refs/heads/master@{#14308}
ssrc taken from packet instead of module removing extra lock
removed unneccesary call to clock_
reduced number of lines.
BUG=webrtc:5565
R=brandtr@webrtc.org
Review URL: https://codereview.webrtc.org/2352023002 .
Cr-Commit-Position: refs/heads/master@{#14307}
This includes if RTCP is received, but the number of packets received by the
other end hasn't increased.
Further, if no RTCP is received for more than 3 feedback intervals (3 seconds)
we start reducing the estimate by 20%. This is put under an experiment.
BUG=webrtc:6238
R=terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2262213002 .
Cr-Commit-Position: refs/heads/master@{#14306}
Trivial patch which fixes an issue where logged rate estimates could be
invalid. E.g. on iOS, two successive timer interrupts can be ~10.5 seconds
and not exactly 10.0 (which is usually the case on Android). In those
cases we could log a rate estimate of e.g. ~51000Hz instead of ~48000Hz.
This CL fixes that.
BUG=NONE
Review-Url: https://codereview.webrtc.org/2350103002
Cr-Commit-Position: refs/heads/master@{#14305}
It requires a new NetEq method, but it can no longer fail. And we no
longer need to use AcmReceiver::decoders_, which we're trying to
eliminate.
(This is a re-land of https://codereview.webrtc.org/2342313002.)
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2348233002
Cr-Commit-Position: refs/heads/master@{#14304}
This change adds a new statistic for logging how many calls to
NetEq::GetAudio resulted in a "muted output". A muted output happens
if the packet stream has been dead for some time (and the last decoded
packet was not comfort noise).
BUG=webrtc:5606
BUG=b/31256483
Review-Url: https://codereview.webrtc.org/2341293002
Cr-Commit-Position: refs/heads/master@{#14302}
It allows the decoder to split the input up into usable chunks before
they are put into NetEq's PacketBuffer. Eventually, all packet splitting
will move into ParsePayload.
There's currently a base implementation of ParsePayload. It will
generate a single Frame that calls the underlying AudioDecoder for
getting Duration() and to Decode.
BUG=webrtc:5805
BUG=chromium:428099
Review-Url: https://codereview.webrtc.org/2326953003
Cr-Commit-Position: refs/heads/master@{#14300}
Reason for revert:
Broke a downstream user of SSLStreamAdapter. Need to add the new interface (returning error code instead of bool) in a backwards compatible way.
Original issue's description:
> Allow the DTLS fingerprint verification to occur after the handshake.
>
> 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
> R=mattdr@webrtc.org, pthatcher@webrtc.org
>
> Committed: https://crrev.com/042041bf9585f92e962387c59ca805f1218338f9
> Cr-Commit-Position: refs/heads/master@{#14296}
TBR=pthatcher@webrtc.org,mattdr@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:6387
Review-Url: https://codereview.webrtc.org/2352863003
Cr-Commit-Position: refs/heads/master@{#14298}
Previously when a Turn port is pruned, if its candidate has been sent to the remote side, the remote side will keep the candidate and use that to create connections.
We now signal the remote side to remove the candidates so that at least no new connection will be created using the removed candidates.
Also updated the virtual socket server to better support our test cases.
1. Allow the virtual socket server to set transit delay for packets sent from a given IP address.
2. Ensure the ordered packet delivery for each socket (Previously the delivery order is enforced on the whole test case, so if a udp packet gets delayed based on its IP address, all TCP packets sent after the UDP packet will be delayed at least until the UDP packet is received).
BUG=webrtc:6380
R=deadbeef@webrtc.org, pthatcher@webrtc.org, skvlad@webrtc.org
Review URL: https://codereview.webrtc.org/2261523004 .
Cr-Commit-Position: refs/heads/master@{#14297}
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
R=mattdr@webrtc.org, pthatcher@webrtc.org
Review URL: https://codereview.webrtc.org/2163683003 .
Cr-Commit-Position: refs/heads/master@{#14296}
For some reason the RtcEventLog unit tests were not building and
running. This CL adds these tests to the rtc_unittests target.
They are only built if protobuf support is enabled.
BUG=webrtc:6379
R=stefan@webrtc.org, terelius@webrtc.org
Review URL: https://codereview.webrtc.org/2344383002 .
Cr-Commit-Position: refs/heads/master@{#14295}
With the small number of tests these targets contain, it
makes more sense to gather them into android_junit_tests
instead, which was created to be a high-level target containing
all the junit tests.
BUG=chromium:647390
NOTRY=True
Review-Url: https://codereview.webrtc.org/2347403002
Cr-Commit-Position: refs/heads/master@{#14292}
Also show a descriptive error message if BUG= field is missing.
BUG=webrtc:6326
NOTRY=True
TESTED=Verified the presubmit error using this very same CL (but with BUG= left empty).
Review-Url: https://codereview.webrtc.org/2322843003
Cr-Commit-Position: refs/heads/master@{#14291}
NOTE: the new code is disabled by default in the WebRtcAudioManager to ensure that
OpenSL ES is not accidentally activated in existing clients. There are still some
unresolved issues to sort out before it can be utilized.
Enables possibility to use OpenSL ES based audio in both directions for WebRTC.
All unit tests and demo clients have been tested with the new implementation but
the new support is behind a flag (see above).
More testing is needed before it can be used in the field and additional support for
hardware effects is still missing.
BUG=webrtc:5925
R=tommi@webrtc.org
Review URL: https://codereview.webrtc.org/2119633004 .
Cr-Commit-Position: refs/heads/master@{#14290}
In the new implementation session reports all events through
CameraSession.Events interface. CameraCapturer passes these events
forward.
BUG=webrtc:6325
Review-Url: https://codereview.webrtc.org/2331343010
Cr-Commit-Position: refs/heads/master@{#14286}
Reason for revert:
Will fix android build failure.
Original issue's description:
> Revert of Update test code to use I420Buffer when writing pixel data. (patchset #2 id:140001 of https://codereview.webrtc.org/2342783003/ )
>
> Reason for revert:
> I was too impatient; this made android builds fail instead. See https://build.chromium.org/p/client.webrtc/builders/Linux32%20ARM/builds/585/steps/compile/logs/stdio
>
> Original issue's description:
> > Reland of Update test code to use I420Buffer when writing pixel data. (patchset #1 id:1 of https://codereview.webrtc.org/2342123003/ )
> >
> > Reason for revert:
> > Intending to fix problem and reland.
> >
> > Original issue's description:
> > > Revert of Update test code to use I420Buffer when writing pixel data. (patchset #5 id:80001 of https://codereview.webrtc.org/2333373007/ )
> > >
> > > Reason for revert:
> > > Fails 64-bit windows builds, it turns out I missed some of the needed int/size_t casts. Example https://build.chromium.org/p/client.webrtc/waterfall?builder=Win64%20Release
> > >
> > > Hope our windows try bots get back in working shape soon.
> > >
> > > Original issue's description:
> > > > Update test code to use I420Buffer when writing pixel data.
> > > >
> > > > VideoFrameBuffer and VideoFrame will become immutable.
> > > >
> > > > BUG=webrtc:5921
> > > > R=magjed@webrtc.org, phoglund@webrtc.org
> > > >
> > > > Committed: https://crrev.com/280ad1514e44bf6717e5871526dd4632f759eb3d
> > > > Cr-Commit-Position: refs/heads/master@{#14249}
> > >
> > > TBR=phoglund@webrtc.org,palmkvist@webrtc.org,magjed@webrtc.org
> > > # Skipping CQ checks because original CL landed less than 1 days ago.
> > > NOPRESUBMIT=true
> > > NOTREECHECKS=true
> > > NOTRY=true
> > > BUG=webrtc:5921
> > >
> > > Committed: https://crrev.com/fbf14607267adf03d235273283ca452a1e564861
> > > Cr-Commit-Position: refs/heads/master@{#14251}
> >
> > TBR=phoglund@webrtc.org,palmkvist@webrtc.org,magjed@webrtc.org
> > # Skipping CQ checks because original CL landed less than 1 days ago.
> > NOPRESUBMIT=true
> > NOTREECHECKS=true
> > NOTRY=true
> > BUG=webrtc:5921
> >
> > Committed: https://crrev.com/d21534a8cfe636bbcf3d7bb151945590abc92b2a
> > Cr-Commit-Position: refs/heads/master@{#14258}
>
> TBR=phoglund@webrtc.org,palmkvist@webrtc.org,magjed@webrtc.org
> # Skipping CQ checks because original CL landed less than 1 days ago.
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=webrtc:5921
>
> Committed: https://crrev.com/3011627142bccdd73fce9fec854abb1f6b02b5c1
> Cr-Commit-Position: refs/heads/master@{#14259}
TBR=phoglund@webrtc.org,palmkvist@webrtc.org,magjed@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
BUG=webrtc:5921
Review-Url: https://codereview.webrtc.org/2347863002
Cr-Commit-Position: refs/heads/master@{#14283}
In the migration to GN templates, some targets got the whole
rtc_common_config removed, which can have unpredicted consequences
in terms of different code behavior due to defines not being set
as expected etc.
It's better to enable this config and only disable the warnings
that fails the build.
BUG=webrtc:6306,webrtc:6307,webrtc:6308
NOTRY=True
Review-Url: https://codereview.webrtc.org/2347263002
Cr-Commit-Position: refs/heads/master@{#14280}
Reason for revert:
Seems to have broken Chromium tests.
Original issue's description:
> AcmReceiver: Look up last decoder in NetEq's table of decoders
>
> AcmReceiver::decoders_ is now one step closer to being unused.
>
> BUG=webrtc:5801
>
> Committed: https://crrev.com/1e4d8b574cde64d93b98d89c7b817fb93185a307
> Cr-Commit-Position: refs/heads/master@{#14274}
TBR=ossu@webrtc.org,henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2348123002
Cr-Commit-Position: refs/heads/master@{#14279}
Reason for revert:
Seems to have broken Chromium tests.
Original issue's description:
> AcmReceiver: Ask NetEq to delete all decoders at once instead of one by one
>
> It requires a new NetEq method, but it can no longer fail. And we no
> longer need to use AcmReceiver::decoders_, which we're trying to
> eliminate.
>
> BUG=webrtc:5801
>
> Committed: https://crrev.com/f6232b43a176e1717354b671a0a52b887d70de59
> Cr-Commit-Position: refs/heads/master@{#14275}
TBR=ossu@webrtc.org,henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2349973002
Cr-Commit-Position: refs/heads/master@{#14278}
Reason for revert:
Seems to have broken Chromium tests.
Original issue's description:
> AcmReceiver::DecoderByPayloadType: Ask NetEq for decoder
>
> Instead of looking in AcmReceiver::decoders_, which we're trying to
> get rid of.
>
> BUG=webrtc:5801
>
> Committed: https://crrev.com/07772e4738ef8007280f97a0245eef34b9ca9391
> Cr-Commit-Position: refs/heads/master@{#14276}
TBR=ossu@webrtc.org,henrik.lundin@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2346173002
Cr-Commit-Position: refs/heads/master@{#14277}
Instead of looking in AcmReceiver::decoders_, which we're trying to
get rid of.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2341283002
Cr-Commit-Position: refs/heads/master@{#14276}
It requires a new NetEq method, but it can no longer fail. And we no
longer need to use AcmReceiver::decoders_, which we're trying to
eliminate.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2342313002
Cr-Commit-Position: refs/heads/master@{#14275}
AcmReceiver::decoders_ is now one step closer to being unused.
BUG=webrtc:5801
Review-Url: https://codereview.webrtc.org/2339953002
Cr-Commit-Position: refs/heads/master@{#14274}
Reason for revert:
Import breakage has been fixed.
Original issue's description:
> Revert of Optimize Android NV12 capture (patchset #2 id:20001 of https://codereview.webrtc.org/2317443003/ )
>
> Reason for revert:
> Import breakage in g3.
>
> Original issue's description:
> > Optimize Android NV12 capture
> >
> > This CL optimizes the Android capture NV12 -> I420 + scaling code. For
> > example, when the input is 1280x720 and we adapt to 640x360, this CL:
> > - Reduces conversion time from 3.37 ms to 1.46 ms.
> > - Reduces memory footprint by 1 MB.
> >
> > BUG=webrtc:6319
> >
> > Committed: https://crrev.com/36d38cbb153e19bdc3c62a750aba6889da40aac2
> > Cr-Commit-Position: refs/heads/master@{#14167}
>
> TBR=sakal@webrtc.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=webrtc:6319
TBR=sakal@webrtc.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=webrtc:6319
Review-Url: https://codereview.webrtc.org/2332213011
Cr-Commit-Position: refs/heads/master@{#14273}
methods inside the audio processing module for the purpose of
increasing code readability.
BUG=
Review-Url: https://codereview.webrtc.org/2335633002
Cr-Commit-Position: refs/heads/master@{#14269}
Adds new method VideoSendStream::SetSource(rtc::VideoSourceInterface* and VieEncoder::SetSource(rtc::VideoSourceInterface*)
This is the first step needed in order for the ViEEncoder to request downscaling using rtc::VideoSinkWants instead of separately reporting CPU overuse and internally doing downscaling due to QP values
This cl
Revert "Revert of Replace interface VideoCapturerInput with VideoSinkInterface. (patchset #13 id:280001 of https://codereview.webrtc.org/2257413002/ )"
This reverts commit 9fdbda6aa3f66ea872344c22e79b23361047cbab.
and fix the problem in the original cl in video_quality_test.cc
BUG=webrtc:5687
TBR=mflodman@webrtc.org
Review-Url: https://codereview.webrtc.org/2348533002
Cr-Commit-Position: refs/heads/master@{#14265}
