Due to a previous refactoring, the SCTP packet header is only added when
the first chunk is written. This wasn't reflected in the
`bytes_remaining`, which made it add more than could fit within the MTU.
Additionally, the maximum packet size must be even divisible by four as
padding will be added to chunks that are not even divisble by four (up
to three bytes of padding). So compensate for that.
Bug: webrtc:12614
Change-Id: I6b57dfbf88d1fcfcbf443038915dd180e796191a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215145
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33760}
BaseChannel adds and removes receive streams on the worker thread
(UpdateRemoteStreams_w) and then posts a task to the network thread to
update the demuxer criteria. Until this happens, OnRtpPacket() keeps
forwarding "recently removed" ssrc packets to the WebRtcVideoChannel.
Furthermore WebRtcVideoChannel::OnPacketReceived() posts task from the
network thread to the worker thread, so even if the demuxer criteria was
instantly updated we would still have an issue of in-flight packets for
old ssrcs arriving late on the worker thread inside WebRtcVideoChannel.
The wrong ssrc could also arrive when the demuxer goes from forwarding
all packets to a single m= section to forwarding to different m=
sections. In this case we get packets with an ssrc for a recently
created m= section and the ssrc was never intended for our channel.
This is a problem because when WebRtcVideoChannel sees an unknown ssrc
it treats it as an unsignalled stream, creating and destroying default
streams which can be very expensive and introduce large delays when lots
of packets are queued up.
This CL addresses the issue with callbacks for when a demuxer criteria
update is pending and when it has completed. During this window of time,
WebRtcVideoChannel will drop packets for unknown ssrcs.
This approach fixes the race without introducing any new locks and
packets belonging to ssrcs that were not removed continue to be
forwarded even if a demuxer criteria update is pending. This should make
a=inactive for 50p receive streams a glitch-free experience.
Bug: webrtc:12258, chromium:1069603
Change-Id: I30d85f53d84e7eddf7d21380fb608631863aad21
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214964
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33757}
This denies the ability to request RTP data channels to callers.
Later CLs will rip out the actual code for creating these channels.
Bug: chromium:928706
Change-Id: Ibb54197f192f567984a348f1539c26be120903f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177901
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33740}
When fixing so that RemoteAudioSource does not end the track just
because the audio channel is gone in Unified Plan[1], this made it
possible for ~PeerConnection to delete all objects, including deleting
the MediaStreamTrack and its RemoteAudioSource, when all tracks are not
in an ended state.
In a real application or Chromium, the PeerConnection would not be
destroyed prior to closing and not hit this DCHECK. But in upstream
dependent projects' unit tests, it would be possible for ref counted
tracks to be destroyed when the track are still kLive, and as a
side-effect hit this DCHECK.
sinks_ is just a list of raw pointers, and whether or not we have done
sinks_.clear() prior to destruction is irrelevant going forward.
[1] https://webrtc-review.googlesource.com/c/src/+/214136
Bug: chromium:1121454
Change-Id: If6cf3dffcd3cb47d46694755b5dc45fa381285fc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215226
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33739}
Like aom and openh264, VP9 can be disabled with the gn argument.
Bug: None
Change-Id: I7d67e3946afae0bb4cac8a7e591445604dda9ce1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215260
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33737}
- Bug fix: the desired initial gain quickly dropped to 0 dB hence
starting a call with a too low level
- New tuning to make AGC2 more robust to VAD mistakes
- Smarter max gain increase speed: to deal with an increased threshold
of adjacent speech frames, the gain applier temporarily allows a
faster gain increase to deal with a longer time spent waiting for
enough speech frames in a row to be observed
- Saturation protector isolated from `AdaptiveModeLevelEstimator` to
simplify the unit tests for the latter (non bit-exact change)
- AGC2 adaptive digital config: unnecessary params deprecated
- Code readability improvements
- Data dumps clean-up and better naming
Bug: webrtc:7494
Change-Id: I4e36059bdf2566cc2a7e1a7e95b7430ba9ae9844
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215140
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33736}
In RtpVideoStreamReceiver2 it can be protected by the `worker_task_checker_` instead.
Bug: webrtc:12579
Change-Id: I4f7d64f16172139eddc7a3e07d1dbbf338beaf2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215224
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33734}
The current noise level estimator has a bug due to which the estimated
level decays to the lower bound in a few seconds when speech is observed.
Instead of fixing the current implementation, which is based on a
stationarity classifier, an alternative, lightweight, noise floor
estimator has been added and tuned for AGC2.
Tested on several AEC dumps including HW mute, music and fast talking.
Bug: webrtc:7494
Change-Id: Iae4cff9fc955a716878f830957e893cd5bc59446
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214133
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33733}
Before these changes default initialized iOS wrappers
around various RTP*Parameters types had their own
default values of nonnull values, which did not always
matched default values from native code, which then causes
override of default native values, if library user didn't
specified it's own initialization.
After these changes default initialization of iOS wrappers
uses default property values from default initialized
native types.
Bug: None
Change-Id: Ie21a7dc38ddc3862aca8ec424859c776c67b1388
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215220
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Kári Helgason <kthelgason@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33731}
Also removing a count check from DestroyTransceiverChannel that's
not useful right now. We can bring it back when we have
DestroyChannelInterface better under control as far as Invokes goes.
Bug: none
Change-Id: I8e9c55a980f8f20e8b996fdc461fd90b0fbd4f3d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215201
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33730}
This reverts commit a743303211b89bbcf4cea438ee797bbbc7b59e80.
Reason for revert: Breaks downstream tests that attempt to call FindHeaderExtensionByUri with 2 arguments. Could you keep the old 2-argument method declaration and just forward the call to the new 3-argument method with a suitable no-op filter?
Original change's description:
> Fix RTP header extension encryption
>
> Previously, RTP header extensions with encryption had been filtered
> if the encryption had been activated (not the other way around) which
> was likely an unintended logic inversion.
>
> In addition, it ensures that encrypted RTP header extensions are only
> negotiated if RTP header extension encryption is turned on. Formerly,
> which extensions had been negotiated depended on the order in which
> they were inserted, regardless of whether or not header encryption was
> actually enabled, leading to no extensions being sent on the wire.
>
> Further changes:
>
> - If RTP header encryption enabled, prefer encrypted extensions over
> non-encrypted extensions
> - Add most extensions to list of extensions supported for encryption
> - Discard encrypted extensions in a session description in case encryption
> is not supported for that extension
>
> Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
> into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
> header extensions will prevent any RTP packets being sent/received.
>
> Bug: webrtc:11713
> Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Taylor <deadbeef@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33723}
TBR=deadbeef@webrtc.org,terelius@webrtc.org,hta@webrtc.org,lennart.grahl@gmail.com
Change-Id: I7df6b0fa611c6496dccdfb09a65ff33ae4a52b26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11713
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215222
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33727}
To be able to use them type-safely, they should support native
operators (e.g. adding a time and a duration, or subtracting two time
values), as the alternative is to manage them as numbers.
Yes, this makes them behave a bit like absl::Time/absl::Duration.
Bug: webrtc:12614
Change-Id: I4dea12e33698a46e71fb549f44c06f2f381c9201
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215143
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33725}
Many things are omitted in this doc and it can definitely be improved,
but I hope it captures the most important parts.
Bug: webrtc:12568
Change-Id: I13097d633ca19cecc9dd43bdb777b0ca48f151dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215142
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33724}
Previously, RTP header extensions with encryption had been filtered
if the encryption had been activated (not the other way around) which
was likely an unintended logic inversion.
In addition, it ensures that encrypted RTP header extensions are only
negotiated if RTP header extension encryption is turned on. Formerly,
which extensions had been negotiated depended on the order in which
they were inserted, regardless of whether or not header encryption was
actually enabled, leading to no extensions being sent on the wire.
Further changes:
- If RTP header encryption enabled, prefer encrypted extensions over
non-encrypted extensions
- Add most extensions to list of extensions supported for encryption
- Discard encrypted extensions in a session description in case encryption
is not supported for that extension
Note that this depends on https://github.com/cisco/libsrtp/pull/491 to get
into libwebrtc (cherry-pick or bump libsrtp version). Otherwise, two-byte
header extensions will prevent any RTP packets being sent/received.
Bug: webrtc:11713
Change-Id: Ia0779453d342fa11e06996d9bc2d3c826f3466d3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/177980
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Taylor <deadbeef@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33723}
Erle Uncertainty changes the residual echo computation during saturated
echo. However, the case of saturated echo is already handled by the
residual echo estimator causing the ErleUncertainty to be a no-op.
The change has been tested for bit-exactness.
Bug: webrtc:8671
Change-Id: I779ba67f99f29d4475a0465d05da03d42d50e075
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215072
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33719}
As part of adding the new WgcCapturerWin implementation of the
DesktopCapturer interface, we should ensure that we can measure the
health and success of this new code. In order to quantify that, I've
added telemetry to measure the usage of each capturer implementation,
the time taken to capture a frame, and any errors that are encountered
in the new implementation.
I've also set the capturer id property of frames so that we can measure
error rates and performance of each implementation in Chromium as well.
This CL must be completed after this Chromium CL lands:
2806094: Add histograms to record new WebRTC DesktopCapturer telemetry | https://chromium-review.googlesource.com/c/chromium/src/+/2806094
Bug: webrtc:9273
Change-Id: I33b0a008568a4df4f95e705271badc3313872f17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214060
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33716}
* `AddTo` and `Difference` are made into static methods, as one may have
believed that these modified the current object previously. The
`Increment` method is kept, as it's obvious that it modifies the
current object as it doesn't have a return value, and `next_value` is
kept, as its naming (lower-case, snake) indicates that it's a simple
accessor.
* Difference will return the absolute difference. This is actually the
only reasonable choice, as the return value was unsigned and any
negative value would just wrap.
Bug: webrtc:12614
Change-Id: If14a71636e67fc612d12759dc80a9c2518c85281
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215069
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33714}
