'configured_bitrate_bps_' is accessed from different threads in
SetBitrate and GetBitrate (one comes back from OnNetworkRouteChange
callback, the other one is used in GetStats()) and so it should be
protected by a critical section.
Bug: webrtc:10010
Change-Id: I029baa729e0203b9f2d180d8835d61add26e6cef
Reviewed-on: https://webrtc-review.googlesource.com/c/111281
Commit-Queue: Peter Slatala <psla@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25675}
This is a preparation for deleting ChannelSendProxy. Signature is
changed on a couple of methods. Unused methods
EnableAudioNetworkAdaptor, DisableAudioNetworkAdaptor,
SetReceiverFrameLengthRange and RtpRtcpModulePtr are deleted. Some
methods are demoted to private: SendData, SendRtp, SendRtcp,
PreferredSampleRate, Sending, and OnOverheadChanged.
Bug: webrtc:9801
Change-Id: I982e72418a32e66fb5de410350b1bfebd9a3219c
Reviewed-on: https://webrtc-review.googlesource.com/c/110605
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25666}
This is a follow up of https://webrtc-review.googlesource.com/c/src/+/43201.
Issue 43201 didn't do the job properly.
1. The audio rtcp report interval is not properly hooked up.
2. We don't need to propagate audio rtcp interval into video send stream or vice versa.
3. We don't need to propagate rtcp report interval to any receiving streams.
Bug: webrtc:8789
Change-Id: I1f637d6e5173608564ef0702d7eda6fc93b3200f
Reviewed-on: https://webrtc-review.googlesource.com/c/110105
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Jiawei Ou <ouj@fb.com>
Cr-Commit-Position: refs/heads/master@{#25610}
This reverts commit 9a0662ac7e4a3bc6b3a316397a7fdf25f0025d35.
Reason for revert: breaks some av sync perf tests
Original change's description:
> Use only first payload timestamp for RTCP SR generation for audio
>
> Since now RTP rate is set correctly for audio, there's no need to
> use the very last data packet rtp/capture timestamps for generating
> RTCP SR packets.
>
> Using only one (first) packet timestamp eliminates the jitter between
> rtp and capture timestamps for audio. This jitter comes from the fact
> that capture timestamp for audio is unknown and we generate bogus
> timestamp at arbitrary, non-constant offset from the real capture time.
>
> Bug: webrtc:9905
> Change-Id: I855556184cfe994be39ab7780836a050f5a38c35
> Reviewed-on: https://webrtc-review.googlesource.com/c/108580
> Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#25430}
TBR=danilchap@webrtc.org,ilnik@webrtc.org,ossu@webrtc.org
Change-Id: I208a659379b1075258ee94613e42afd9aebe4754
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:9905
Reviewed-on: https://webrtc-review.googlesource.com/c/108623
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25435}
Since now RTP rate is set correctly for audio, there's no need to
use the very last data packet rtp/capture timestamps for generating
RTCP SR packets.
Using only one (first) packet timestamp eliminates the jitter between
rtp and capture timestamps for audio. This jitter comes from the fact
that capture timestamp for audio is unknown and we generate bogus
timestamp at arbitrary, non-constant offset from the real capture time.
Bug: webrtc:9905
Change-Id: I855556184cfe994be39ab7780836a050f5a38c35
Reviewed-on: https://webrtc-review.googlesource.com/c/108580
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25430}
This change corrects a potential race condition when updating a FrameEncryptor
for the audio send channel. If a FrameEncryptor is set on an active audio
stream it is possible for the current FrameEncryptor attached to the audio channel to be deallocated due to
the FrameEncryptors reference count reaching zero before the new FrameEncryptor is set on the
channel.
To address this issue the ChannelSend is now holds a scoped_reftptr<FrameEncryptor>
to only allow deallocation when it is actually set on the encoder queue.
ChannelSend is unique in this respect as the Audio Receiver a long with the
Video Sender and Video Receiver streams all recreate themselves when they have
a configuration change. ChannelSend instead reconfigures itself using the
existing channel object.
Added Seth as TBR as this only introduces mocks.
TBR=shampson@webrtc.org
Bug: webrtc:9907
Change-Id: Ibf391dc9cecdbed1874e0252ff5c2cb92a5c64f4
Reviewed-on: https://webrtc-review.googlesource.com/c/107664
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Qingsi Wang <qingsi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25374}
This change adds a new subcategory to the public native webrtc::CryptoOptions
structure: webrtc::CryptoOptions::Frame.
This new structure has a single off by default property:
crypto_options.frame.require_frame_encryption.
This new flag if set prevents RtpSenders from sending outgoing payloads unless
a frame_encryptor_ is attached and prevents RtpReceivers from receiving
incoming payloads unless a frame_decryptor_ is attached.
This option is important to enforce no unencrypted data can ever leave the
device or be received.
I have also attached bindings for Java and Objective-C.
I have implemented this functionality for E2EE audio but not E2EE video
since the changes are still in review.
Bug: webrtc:9681
Change-Id: Ie184711190e0cdf5ac781f69e9489ceec904736f
Reviewed-on: https://webrtc-review.googlesource.com/c/105540
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Oskar Sundbom <ossu@webrtc.org>
Reviewed-by: Sami Kalliomäki <sakal@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25238}
This change integrates the FrameDecryptorInterface and the FrameEncryptorInterface into
the audio media path. If a FrameEncryptorInterface is set on an outgoing audio RTPSender
then each outgoing audio payload will first pass through the provided FrameEncryptor which
will have a chance to modify the payload contents for the purposes of encryption.
If a FrameDecryptorInterface is set on an incoming audio RtpReceiver then each incoming
audio payload will first pass through the provided FrameDecryptor which have a chance to
modify the payload contents for the purpose of decryption.
While AEAD is supported by the FrameDecryptor/FrameEncryptor interfaces this CL does not
use it and so it is left as null.
Bug: webrtc:9681
Change-Id: Ic383a9dce280528739f9d271357c2220e0a0dccf
Reviewed-on: https://webrtc-review.googlesource.com/c/101702
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Emad Omara <emadomara@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25001}
