[1/2] - Make new version pure-virtual, and deprecated version non-pure.
This will allow deleting the deprecated version from downstream
projects.
[2/2] - Remove deprecated version.
TBR=stefan@webrtc.org
Bug: webrtc:10336
Change-Id: Ia132ef071b1f379fc74834178e75e981ca908125
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/144042
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28413}
This change replaces the `ContributingSources`-implementation of `GetContributingSources()` and `GetSynchronizationSources()` on the video side with the spec-compliant `SourceTracker`-implementation.
The most noticeable impact is that the per-frame dictionaries are now updated when frames are delivered to the RTCRtpReceiver's MediaStreamTrack rather than when RTP packets are received on the network.
Bug: webrtc:10545
Change-Id: I895b5790280ac94c1501801d226c643633c67349
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/143177
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/master@{#28386}
Loss notifications may either be sent immediately, or wait until another
RTCP feedback message is sent.
Bug: webrtc:10336
Change-Id: I40601d9fa1dec6c17b2ce905cb0c8cd2dcff7893
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139242
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28142}
Currently, if LNTF and NACK messages are both created, they will
be sent out in separate RTCP messages. This is wasteful.
This CL is the first of in a series of CLs that will ensure that
these feedback messages can be buffered together, without introducing
more of a delay than the CPU time required to process both messages.
Bug: webrtc:10336
Change-Id: I950324112ee346695a12a17d025483ea5e99c732
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139112
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28136}
This is a partial revert of
https://webrtc-review.googlesource.com/c/src/+/130101.
The KeyFrameRequestSender argument is added back to the constructor of
RtpVideoStreamReceiver. It is optional; if a null pointer is passed,
key frame requests are sent via the internal RtpRtcp module, and this is
how the class is used by VideoReceiveStream. An injectable
KeyFrameRequestSender is useful for tests, for downstream applications
that want to route key frame requests elsewhere, and should also aid
later migration to RtcpTransciever.
Bug: None
Change-Id: Idf9baeed21570625ad74e9afbe38f7ea5bf79feb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/139107
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#28102}
RtpVideoStreamReceiver used to pass the PacketRouter when creating its
RtpRtcp module, but it's not needed for a receive-only module. Make the
PacketRouter optional to the constructor; it's used only for registering
the created RtpRtcp module as a candidate for sending rtcp feedback.
Bug: None
Change-Id: I371a0bdb9d68ac48b16f52e1d7939f8c177dc528
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/137429
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27984}
The latter is also a member of the former. This cleanup is also
a preparation for dropping WebRtcRTPHeader::frameType (or deleting
WebRtcRTPHeader right away), now that it's a video-specific member.
Tbr: kwiberg@webrtc.org # Comment change in modules/include/
Bug: None
Change-Id: I5c1f3f981f0d750713fc9b9b145278150fe32b5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133024
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27740}
It's called from VideoReceiver::Process, which we no longer use.
Bug: webrtc:7408
Change-Id: I2ce5b7a07437e110d20d04aa159dddf245504abe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133189
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27657}
This reverts commit 7dd83e2bf73a7f1746c5ee976939bf52e19fa8be.
Reason for revert: This wasn't the cause of the break.
Original change's description:
> Revert "Refactor FrameDecryptorInterface::Decrypt to use new API."
>
> This reverts commit 642aa81f7d5cc55d5b99e2abc51327eed9d40195.
>
> Reason for revert: Speculative revert. The chromium roll is failing:
> https://ci.chromium.org/p/chromium/builders/try/linux-rel/64388
> But I can't figure out exactly what is failing, this looks suspecious.
>
> Original change's description:
> > Refactor FrameDecryptorInterface::Decrypt to use new API.
> >
> > This change refactors the FrameDecryptorInterface to use the new API. The new
> > API surface simply moves bytes_written to the return type and implements a
> > simple Status type.
> >
> > Bug: webrtc:10512
> > Change-Id: I622c5d344d58e618853c94c2f691cf7c8fb73a36
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/131460
> > Reviewed-by: Steve Anton <steveanton@webrtc.org>
> > Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> > Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> > Commit-Queue: Benjamin Wright <benwright@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#27497}
>
> TBR=brandtr@webrtc.org,steveanton@webrtc.org,solenberg@webrtc.org,ossu@webrtc.org,stefan@webrtc.org,benwright@webrtc.org
>
> Change-Id: Ia9ec70263762c34671af13f0d519e636eb8473cd
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:10512
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132013
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27510}
TBR=brandtr@webrtc.org,steveanton@webrtc.org,solenberg@webrtc.org,hbos@webrtc.org,ossu@webrtc.org,stefan@webrtc.org,benwright@webrtc.org
Change-Id: I8e4b7965cf1d1a1554c3b46e6245f5ad0d2dcbb4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10512
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/131982
Reviewed-by: Benjamin Wright <benwright@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27529}
This reverts commit 642aa81f7d5cc55d5b99e2abc51327eed9d40195.
Reason for revert: Speculative revert. The chromium roll is failing:
https://ci.chromium.org/p/chromium/builders/try/linux-rel/64388
But I can't figure out exactly what is failing, this looks suspecious.
Original change's description:
> Refactor FrameDecryptorInterface::Decrypt to use new API.
>
> This change refactors the FrameDecryptorInterface to use the new API. The new
> API surface simply moves bytes_written to the return type and implements a
> simple Status type.
>
> Bug: webrtc:10512
> Change-Id: I622c5d344d58e618853c94c2f691cf7c8fb73a36
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/131460
> Reviewed-by: Steve Anton <steveanton@webrtc.org>
> Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Commit-Queue: Benjamin Wright <benwright@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#27497}
TBR=brandtr@webrtc.org,steveanton@webrtc.org,solenberg@webrtc.org,ossu@webrtc.org,stefan@webrtc.org,benwright@webrtc.org
Change-Id: Ia9ec70263762c34671af13f0d519e636eb8473cd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:10512
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/132013
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27510}
This change refactors the FrameDecryptorInterface to use the new API. The new
API surface simply moves bytes_written to the return type and implements a
simple Status type.
Bug: webrtc:10512
Change-Id: I622c5d344d58e618853c94c2f691cf7c8fb73a36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/131460
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27497}
This change introduces new logic to allow the injection of the FrameDecryptor
into an arbitrary already running VideoReceiveStream without resetting it. It
does this by taking advantage of the BufferedFrameDecryptor which will
forcefully be created regardless of whether a FrameDecryptor is passed in
during construction of the VideoReceiver if the
crypto_option.require_frame_encryption is true. By allowing the
BufferedFrameDecryptor to swap out which FrameDecryptor it uses this allows the
Receiver to switch decryptors without resetting the stream.
This is intended to mostly be used when you set your FrameDecryptor at a point
post creation for the first time.
Bug: webrtc:10416
Change-Id: If656b2acc447e2e77537cfa394729e5c3a8b660a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130361
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27458}
VCMReceiveStatisticsCallback originates in the old jitter buffer, and
is no longer used.
VCMFrameTypeCallback originates in VideoReceiver::RequestKeyFrame,
which is called from OncomingPacket, Process, Decode(uint16_t
maxWaitTimeMs), all of which are unused by VideoReceiveStream.
So delete the code to wire them up via VideoStreamDecoder.
Bug: webrtc:7408
Change-Id: I173bc94eb32f2641f943c125083db038c3bcaeb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128870
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27277}
The current Key Frame request system doesn't take into account failed
decryptions and this can lead to WebRTC spamming new key frame requests when
the issue is actually in the decryptor layer. To prevent this if frame
decryption is required for the PeerConnection key frame requests will not be
sent at 200ms intervals but will wait until the stream is decryptable before
utilizing this logic.
Bug: webrtc:10330
Change-Id: I188a21dfd142dec6175d9def95f39a2bc517017c
Reviewed-on: https://webrtc-review.googlesource.com/c/123414
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26931}
* LossNotificationController is the class that decides when to issue
LossNotification RTCP messages.
* RtpRtcp handles the technicalities of producing RTCP messages.
Bug: webrtc:10336
Change-Id: I292536257a984ca85d21d9cfa38e7ff2569cbb39
Reviewed-on: https://webrtc-review.googlesource.com/c/124123
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26840}
The new name fits better.
Bug: None
Change-Id: I1f201ff07915ed6c18efeefb7380e2b286742bb9
Reviewed-on: https://webrtc-review.googlesource.com/c/123800
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26814}
This change introduces a new class BufferedFrameDecryptor that is responsible
for decrypting received encrypted frames and passing them on to the
RtpReferenceFinder. This decoupling refactoring was triggered by a new
optimization also introduced in this patch to stash a small number of
undecryptable frames if no frames have ever been decrypted. The goal of this
optimization is to prevent re-fectching of key frames on low bandwidth networks
simply because the key to decrypt them had not arrived yet.
The optimization will stash 24 frames (about 1 second of video) in a ring buffer
and will attempt to re-decrypt previously received frames on the first valid
decryption. This allows the decoder to receive the key frame without having
to request due to short key delivery latencies. In testing this is actually hit
quite often and saves an entire RTT which can be up to 200ms on a bad network.
As the scope of frame encryption increases in WebRTC and has more specialized
optimizations that do not apply to the general flow it makes sense to move it
to a more explicit bump in the stack protocol that is decoupled from the WebRTC
main flow, similar to how SRTP is utilized with srtp_protect and srtp_unprotect.
One advantage of this approach is the BufferedFrameDecryptor isn't even
constructed if FrameEncryption is not in use.
I have decided against merging the RtpReferenceFinder and EncryptedFrame stash
because it introduced a lot of complexity around the mixed scenario where some
of the frames in the stash are encrypted and others are not. In this case we
would need to mark certain frames as decrypted which appeared to introduce more
complexity than this simple decoupling.
Bug: webrtc:10022
Change-Id: Iab74f7b7d25ef1cdd15c4a76b5daae1cfa24932c
Reviewed-on: https://webrtc-review.googlesource.com/c/112221
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25865}
When FlexFEC is enabled, sometimes media packet will be recovered by FEC before the actual media packet's arrival. In current implementation this will be considered as packet out of order and nack will be sent, thus cause large increase in retransmit bitrate.
This fix:
1. Avoid sending nack for packet out of order caused by "early" recovered media packets.
2. Save recovered media packet in a set, and do not send nack for these packets.
Bug: None
Change-Id: I008ef4e33668bce6d2cb9ff52b4b5c8e3f349965
Reviewed-on: https://webrtc-review.googlesource.com/c/108090
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25444}
This change enables the FrameDecryptor attached to an RtpVideoReceiver to do
an initial request for a KeyFrame if the first successfully decrypted payload
is not a key frame.
Bug: webrtc:9795
Change-Id: I401ce1f513cb51ce520b60dcaf8b825a68d00c7f
Reviewed-on: https://webrtc-review.googlesource.com/c/107246
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25295}
This change integrates the FrameDecryptorInterface and the FrameEncryptorInterface into
the video send and receive path. If a FrameEncryptorInterface is set on an outgoing video RTPSender
then each outgoing video frame will first pass through the provided FrameEncryptor which
will have a chance to modify the payload contents for the purposes of encryption. In addition to
this the new GenericFrameDescriptor will be added as additional data.
If a FrameDecryptorInterface is set on an incoming video RtpReceiver then each incoming
video payload will first pass through the provided FrameDecryptor which have a chance to
modify the payload contents for the purpose of decryption.
Bug: webrtc:9795
Change-Id: I9f743ce0cb63df0cf070f6144be7ada078b4e5d2
Reviewed-on: https://webrtc-review.googlesource.com/c/103920
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25258}
And also drop dependency on module_api, where possible. With this
change, common_video/ no longer depends on
libjingle_peerconnection_api.
Bug: None
Change-Id: Icc0648559bef5b7f549e81d58f2a5f97c0af3abf
Reviewed-on: https://webrtc-review.googlesource.com/c/103782
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24991}
This CL makes the RtpGenericFrameDescriptor available in
RTPSenderVideo::SendVideo for encryption and in
RtpVideoStreamReceiver::OnReceivedFrame for decryption.
Bug: webrtc:9361
Change-Id: I5b6d10138c0874657862f103c8c9a2328e6d4a66
Reviewed-on: https://webrtc-review.googlesource.com/102720
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24929}
Add new method OnRtpPacket, but leave
ReceiveStatisticsImpl::IncomingPacket and most of the implementation
unchanged. Deleting the old method and converting implementation from
RTPHeader to RtpPacketreceived is planned for a followup, after
downstream code is updated.
Bug: webrtc:7135, webrtc:8016
Change-Id: I697ec12804618859f8d69415622d1b957e1d0847
Reviewed-on: https://webrtc-review.googlesource.com/100104
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24889}
Return value always passed as the |retransmitted| argument to
ReceiveStatistics::IncomingPacket. The implementation of this method,
StreamStatisticianImpl::IncomingPacket, can call its own
IsRetransmitOfOldPacket, which is demoted to a private method.
Bug: webrtc:7135
Change-Id: I904db676738689c7a1db4caa588f70e64e3c357d
Reviewed-on: https://webrtc-review.googlesource.com/95649
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24494}
This CL removes //build/config/clang:find_bad_constructs from the
suppressed_configs list, which means that clang:find_bad_constructs
is now enabled on these translation units.
Bug: webrtc:9251, webrtc:163
Change-Id: I74cb86c29cebb69dd22083718f1446f18f705cd4
Reviewed-on: https://webrtc-review.googlesource.com/95883
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24483}
this function is now only used in combination with StreamStatistician::IsRetransmitOfOldPacket
but IsRetransmitOfOldPacket internally checks if packet is in_order, thus making extra check unnecessary
In addition to making code simpler, removing this checks avoids
taking two extra CritSection on common code path of incoming rtp packet.
Bug: webrtc:8016
Change-Id: I050004e256b5698ce700e3416aa86b55f446a270
Reviewed-on: https://webrtc-review.googlesource.com/85361
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23762}
This is a no-op change because rtc::Optional is an alias to absl::optional
This CL generated by running script with parameters 'audio call video':
#!/bin/bash
find $@ -type f \( -name \*.h -o -name \*.cc \) \
-exec sed -i 's|rtc::Optional|absl::optional|g' {} \+ \
-exec sed -i 's|rtc::nullopt|absl::nullopt|g' {} \+ \
-exec sed -i 's|#include "api/optional.h"|#include "absl/types/optional.h"|' {} \+
find $@ -type f -name BUILD.gn \
-exec sed -r -i 's|"(../)*api:optional"|"//third_party/abseil-cpp/absl/types:optional"|' {} \+;
git cl format
Bug: webrtc:9078
Change-Id: I02c5db956846a88a268a300ba086703a02d62e36
Reviewed-on: https://webrtc-review.googlesource.com/83722
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23628}
This is a reland of 3409cfa378e75c0c08d900e0848147929249a62b
Needed to change RtpVideoStreamReceiver to stop deregistering a payload
type if two payload types refer to the same codec (which now happens,
with the packetization mode 0/1 payload types). It's not clear why this
was being done in the first place.
Original change's description:
> Start supporting H264 packetization mode 0.
>
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
>
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
>
> Bug: chromium:600254
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}
Bug: chromium:600254
Change-Id: Ice1acc05acd1543d9b46e918de2bba0694d86259
Reviewed-on: https://webrtc-review.googlesource.com/78399
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23494}
Both of these implementations are added as observers by
VideoReceiveStream, which is also an observer.
Instead, VideoReceiveStream now forward the necessary information
when the stats are updated as is already done for |frame_buffer_|.
Fewer observers registered, simplifies the code a little bit,
reduces synchronization when registering/unregistering observers
and reduces the set of existing implementations.
(I'm changing call_stats.* a little bit, so this is a by-the-way change)
Bug: none
Change-Id: I2d40b80a60e5ca632293c5118ac3b1a35d48ea40
Reviewed-on: https://webrtc-review.googlesource.com/64524
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22594}
