stats.rtp_stats.jitter is a RTP timestamp so we needed to convert it back to regular timestamps
See https://bugs.chromium.org/p/webrtc/issues/detail?id=12980#c7
Bug: webrtc:12980
Change-Id: I0d94a22e043ac6ecec4926d950abbdcf787b7168
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/227100
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Di Wu <meetwudi@gmail.com>
Cr-Commit-Position: refs/heads/master@{#34590}
rtp_rtcp_format is lighter build target than rtc_media_base and
a more natural place to keep rtp parsing functions.
Bug: None
Change-Id: Ibcb5661cc65edbdc89a63f3e411d7ad1218353cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/226330
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34504}
Software fallback wrapper now reports least common multiple of requirements
for two encoders.
SimulcastEncoderAdapter queries actual encoder before InitEncode call
and requests alignment for all layers if simulcast is not supported by
any of the encoders.
Bug: chromium:1084702
Change-Id: Iaed8190737125d447036b6c664b863be72556a5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225881
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34466}
Remove unused functions GetRtpHeader/GetRtpHeaderLength
Replace usage of SetRtpHeader with webrtc::RtpPacket
Move SetRtpSsrc next to the only place it is used.
Bug: None
Change-Id: I3ecc244b1a2bdb2d68e0dbdb34dd60160a3101f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/225547
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34447}
This is a step in the direction of being able to make configuration
changes without having to tear down and reconstruct the object
during renegotiation.
Bug: none
Change-Id: If594fd41f3a561060f64212c479a25d19adf8598
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223740
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34402}
* Remove unnecessary decoder factory pointer.
* Set video decoder factory in the ctor of the config class.
* Prepare SetRecvParameters for not needing RecreateWebRtcVideoStream.
Bug: none
Change-Id: I48fbf2920c9fe50f3995ceab5667eb2f70618f25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223067
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34351}
This builds on a few other CLs that avoid recreating the audio receive
streams on config changes and removes redundant config state in
WebRtcAudioReceiveStream, constructs the embedded receive stream in the
initializer list and keeps it const.
Bug: webrtc:11993
Change-Id: Iad28e0170bee6bf1e08713a89af7c81435b4265e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222100
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34317}
This is a consistent way to get to common config parameters for
all receive streams and avoids storing a copy of the extension
headers inside of Call. This is needed to get rid of the need of
keeping config and copies in sync, which currently is part of why
we repeatedly delete and recreate audio receive streams on config
changes.
Bug: webrtc:11993
Change-Id: Ia356b6cac1425c8c6766abd2e52fdeb73c4a4b4f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/222040
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34285}
Also including common Rtp config members.
Follow up changes will remove the ReceiveRtpConfig class in Call
and copy of extension headers, instead use the config directly
from the receive streams and not require stream recreation for changing
the headers.
Bug: webrtc:11993
Change-Id: I29ff3400d45d5bffddb3ad0a078403eb102afb65
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221983
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34283}
This is to be consistent with how things work on the video side but
also much less drastic than the current implementation. Aim is to
remove RecreateAudioReceiveStream(), which would improve efficiency
as well as allow for specific handling of the cases that currently
trigger recreation.
Bug: webrtc:11993
Change-Id: Ia81a5e66d44e41ea4eb2bff800e0b1583821c96a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221860
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34282}
This CL adds a cooldown of 0.5 seconds where if the WebRtcVideoChannel
created an unsignalled receive stream within that amount of time, if we
receive even more unknown ssrcs we simply drop those RTP packets.
This prevents getting into a state of spawning new decoders on every
single packet which could happen e.g. if PT based demuxing is enabled
and MIDs are missing from the packets.
Bug: webrtc:12815
Change-Id: Id7675fb0cbfbc72281dcfe030d1a35629df3eb9f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221520
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34263}
This reverts commit 8a18e5b3c954a3f9cc006c90356a3d850bcc352f.
Reason for revert: Removing the problematic DCHECK.
Original change's description:
> Revert "Remove AudioReceiveStream::Reconfigure() method."
>
> This reverts commit e2561e17e29e62c02731f1d214d7ee5ffdaeb941.
>
> Reason for revert: Speculative revert: breaks an downstream project
>
> Original change's description:
> > Remove AudioReceiveStream::Reconfigure() method.
> >
> > Instead, adding specific setters that are needed at runtime:
> > * SetDepacketizerToDecoderFrameTransformer
> > * SetDecoderMap
> > * SetUseTransportCcAndNackHistory
> >
> > The whole config struct is big and much of the state it holds, needs to
> > be considered const. For that reason the Reconfigure() method is too
> > broad of an interface since it overwrites the whole config struct
> > and doesn't actually handle all the potential config changes that might
> > occur when the config changes.
> >
> > Bug: webrtc:11993
> > Change-Id: Ia5311978f56b2e136781467e44f0d18039f0bb2d
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221363
> > Reviewed-by: Niels Moller <nisse@webrtc.org>
> > Commit-Queue: Tommi <tommi@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#34252}
>
> TBR=saza@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
>
> Change-Id: I15ca2d8ee5fd612e13dc1f4b3bfb9c885c21dc66
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: webrtc:11993
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221746
> Commit-Queue: Artem Titov <titovartem@webrtc.org>
> Reviewed-by: Andrey Logvin <landrey@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34253}
# Not skipping CQ checks because this is a reland.
Bug: webrtc:11993
Change-Id: I0d3bf9abdcdc8d3f9259d014e6074a5e6b6cc73c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221747
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34255}
This reverts commit e2561e17e29e62c02731f1d214d7ee5ffdaeb941.
Reason for revert: Speculative revert: breaks an downstream project
Original change's description:
> Remove AudioReceiveStream::Reconfigure() method.
>
> Instead, adding specific setters that are needed at runtime:
> * SetDepacketizerToDecoderFrameTransformer
> * SetDecoderMap
> * SetUseTransportCcAndNackHistory
>
> The whole config struct is big and much of the state it holds, needs to
> be considered const. For that reason the Reconfigure() method is too
> broad of an interface since it overwrites the whole config struct
> and doesn't actually handle all the potential config changes that might
> occur when the config changes.
>
> Bug: webrtc:11993
> Change-Id: Ia5311978f56b2e136781467e44f0d18039f0bb2d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221363
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Commit-Queue: Tommi <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#34252}
TBR=saza@webrtc.org,nisse@webrtc.org,tommi@webrtc.org,webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I15ca2d8ee5fd612e13dc1f4b3bfb9c885c21dc66
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11993
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221746
Commit-Queue: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Andrey Logvin <landrey@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34253}
Instead, adding specific setters that are needed at runtime:
* SetDepacketizerToDecoderFrameTransformer
* SetDecoderMap
* SetUseTransportCcAndNackHistory
The whole config struct is big and much of the state it holds, needs to
be considered const. For that reason the Reconfigure() method is too
broad of an interface since it overwrites the whole config struct
and doesn't actually handle all the potential config changes that might
occur when the config changes.
Bug: webrtc:11993
Change-Id: Ia5311978f56b2e136781467e44f0d18039f0bb2d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221363
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34252}
UpdateActiveSimulcastLayers has been blocking
WebRtcVideoChannel::SetSend which may be called quite frequently during
negotiations. This CL changes UpdateActiveSimulcastLayers to not
synchronize with the transport's task queue to wait for the changes to
get applied.
This synchronization is quite costly, but so too are other remaining
things in VideoSendStream, so we should aim to get rid of the
`thread_sync_event_` in VideoSendStream.
Bug: webrtc:12840, webrtc:12854
Change-Id: Idb48d29b6b8382881c7c1e6f1d0f5e708dbca30f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/221203
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34228}
Both flexfec and AV1 seem not to have created interop issues and falling
back to the lower range is better than skipping the codecs.
BUG=webrtc:12295
Change-Id: I58459133beae4f17b767af92a4e2c9028ab8cbe3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217888
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@nvidia.com>
Cr-Commit-Position: refs/heads/master@{#34182}
Starting new audio codecs from the top of the lower range
reduces collisions with video codecs which are assigned from
the bottom of the lower range
BUG=webrtc:11640
Change-Id: If6d2b849b8e1de777a1d4352df533e4f1845fde9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220022
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34166}
for consistency with the definition in IsRtcpPacket which takes
into account a collision of H261 feedback for payload types 64 + 65:
https://datatracker.ietf.org/doc/html/rfc5761#section-4
BUG=webrtc:12194
Change-Id: I2ebb0456ae2aff1b1735f26221c7c4ae79698ac9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/220021
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34131}
With this CL, SimulcastEncoderAdapter no longer configures its encoder
as multi-layered if we only have a single active layer. Instead we
create a single single-layered encoder for that one and only active
layer. When using VP8 SW encoder this means that LibvpxVp8Encoder is
configured to only prepare a single video frame which avoids the cost of
scaling down to layers that we do not send. (A multi-layered
LibvpxVp8Encoder is required to scale even layers we don't encode.)
When profiling this CL I found very small but measurable gains for
representative downscale factors of 20.1 ms of 60 s profile. This is
just 0.0335% CPU so it's not much, but skipping a downscale might be
worth a lot more if we have to map/unmap buffers or do GPU round-trips
in the future (which I have not measured).
When downscaling to factors 4 and 2 due to libyuv having a
"fast-path" for these (i.e. no adaptation active), zero difference was
found for NV12. For I420 there was small regression of 16.1 ms
(0.026% CPU) for this one edge-case. It's possible to work around this,
but considering the tiny changes we're talking about, I really don't
think it's worth the additional complexity. I'll file a bug on libyuv
about scaling factors 2+2 vs 4 and leave it at that.
Bug: webrtc:12603
Change-Id: Id462140c6a829cf6b460baae868e94243f477db3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219683
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34092}
its content is duplicated in the report_block_data member
Bug: webrtc:10678
Change-Id: I89421ae4ab5f727a233161924372105e222ed404
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/219080
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34039}
This is one step in getting rid of cricket::MediaType.
Bug: webrtc:12754
Fixes: webrtc:12764
Change-Id: Idee832572bdc4c0e3bfdec6fb31ec0ba9db3e995
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/218346
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33994}
Pending messages on network thread for MediaChannel, will be dropped
when the MediaChannel object is deleted (without blocking).
Remove MessageHandler inheritance from Channel since Post-ing to the
network thread has been removed from there.
Copy/pasted code for SendRtp/SendRtcp in WebRtcVideoChannel and
WebRtcVoiceMediaChannel consolidated in MediaChannel.
Bug: webrtc:11993
Change-Id: I05320eb7f86b98adba50ca5eb8b76b78f4111263
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217720
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33955}
This CL mostly adds plumbing to get awareness of the network thread
to the media channel classes. Currently this pointer is only used
to DCHECK that `SetInterface` for the `NetworkInterface` pointer, is
called on the network thread. Follow up changes will establish that
most of the methods are called on the network thread and the mutex
in the MediaChannel base class, can be removed.
Most of the changes in the CL are in channel_unittest.cc. They're mostly
around updating the tests to incorporate the network thread in ways
that reflect how the classes are used in production. Another change is
to use accessor methods for the media channel instances instead of
caching potentially dangling pointers.
Bug: webrtc:11993
Change-Id: I8e2ed1bc23724e238554dbce386789d69660f7e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217682
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33951}
This is related to upcoming changes whereby it will be enforced that
calls to SetInterface(<valid ptr>) and SetInterface(nullptr) be matched
up correctly.
Bug: webrtc:11993
Change-Id: Ic022f9487a7ab297adaced8e620e2384e055673b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217241
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33903}
There's a bit of copy/pasted code in the channel code, which is
making moving network traffic consistently over to the network thread
a bit trickier than it needs to be, so I'm also updating variable
names used in Set[Local|Remote]Content_w to be more explicitly the same
and make it clear that the code is copy/pasted (and future updates can
consolidate more of it).
Also removing some code from the video/voice media channels that's
effectively dead code (vector + registration methods that aren't needed)
Bug: webrtc:12705
Change-Id: I2e14e69fbc489a64fc1e8899aaf1cfc979fe840b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215978
Reviewed-by: Sam Zackrisson <saza@google.com>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33847}
SdpVideoFormat is used to configure video encoder and decoders.
This CL adds support for comparing two SdpVideoFormat objects
to determine if they specify the same video codec.
This functionality previously only existed in media/base/codec.h
which made the code sensitive to circular dependencies. Once
downstream projects stop using cricket::IsSameCodec, this code
can be removed.
Bug: chromium:1187565
Change-Id: I242069aa6af07917637384c80ee4820887defc7d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213427
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33794}
This is a refactor to simplify a follow-up CL of adding
SdpVideoFormat::IsSameCodec.
The original files media/base/h264_profile_level_id.* and
media/base/vp9_profile.h must be kept until downstream projects
stop using them.
Bug: chroimium:1187565
Change-Id: Ib39eca095a3d61939a914d9bffaf4b891ddd222f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215236
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Kári Helgason <kthelgason@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33782}
* Adds a OnPacketSent callback to MediaChannel, which matches with
MediaChannel::NetworkInterface::SendPacket.
* Moves the OnPacketSent handling to the media channel implementations
(video/voice) and removes the PeerConnection/SdpOfferAnswerHandler
layer from the call path.
* Call::OnSentPacket is called directly from the channels on the network
thread. This eliminates a PostTask to the worker thread for every
audio/video network packet.
* Remove sigslot dependency from MediaChannel (and derived).
Bug: webrtc:11993
Change-Id: I1f79a7aa60f05d47e1882f9be1c9323ea8fac5f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215403
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33777}
Classes associated with the Call instance, need access to these threads
and/or awareness, for checking for thread correctness.
Bug: webrtc:11993
Change-Id: I93bcee0657875f211be2ec959b96f818fa9fd8a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/215584
Reviewed-by: Markus Handell <handellm@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33772}
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 change adds support for emitting encoded frames
for recording when the decoder can't easily read out
encoded width and height as is the case for AV1 streams,
in which case the information is buried in OBUs. Downstream
project relies on resolution information being present for key
frames. With the change, VideoReceiveStream2 infers the
resolution from decoded frames, and supplies it in the
RecordableEncodedFrames.
Bug: chromium:1191972
Change-Id: I07beda6526206c80a732976e8e19d3581489b8fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214126
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33662}
provides an implementation of the rtx-time parameter from
https://tools.ietf.org/html/rfc4588#section-8
that determines the maximum time a receiver waits for a frame
before sending a PLI.
BUG=webrtc:12420
Change-Id: Iff20d92c806989cd4d56fe330d105b3dd127ed24
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201400
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33627}
* A ChannelManager instance is now created via ChannelManager::Create()
* Initialization is performed inside Create(), RAII.
* All member variables in CM are now either const or RTC_GUARDED_BY
the worker thread.
* Removed dead code (initialization and capturing states are gone).
* ChannelManager now requires construction/destruction on worker thread.
- one fewer threads that its aware of.
* media_engine_ pointer removed from ConnectionContext.
* Thread policy changes moved from ChannelManager to ConnectionContext.
These changes will make a few other issues easier to fix, so tagging
those bugs with this CL.
Bug: webrtc:12601, webrtc:11988, webrtc:11992, webrtc:11994
Change-Id: I3284cf0a08c773e628af4124e8f52e9faddbe57a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212617
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33614}
Changes:
- adding the `RTCRemoteOutboundRtpStreamStats` dictionary (see [1])
- collection of remote outbound stats (only for audio streams)
- adding `remote_id` to the inbound stats and set with the ID of the
corresponding remote outbound stats only if the latter are available
- unit tests
[1] https://www.w3.org/TR/webrtc-stats/#dom-rtcremoteoutboundrtpstreamstats
Tested: verified from chrome://webrtc-internals during an appr.tc call
Bug: webrtc:12529
Change-Id: Ide91dc04a3c387ba439618a9c6b64a95994a1940
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211042
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33545}
This is to allow FEC to be encoded at the lowest bitrate.
Bug: chromium:1086942
Change-Id: I1d30276a9a2aaa80016250dc786d5d867ba6cd10
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212501
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#33539}
Ensures that the value read by the audio thread is well-defined.
Bug: b/176104610
Change-Id: I15d1901522be79703b3dc188fbe03c752be09a60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212442
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Per Åhgren <peah@webrtc.org>
Commit-Queue: Gustaf Ullberg <gustaf@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33503}
