The constants are being made private since no new code should use them.
However, the helper functions sill uses "AV1X" internally for backwards
compatibility.
Bug: webrtc:13166
Change-Id: I0a0cd46f31ca70bb7f395c9b1e9cdb202df11f6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236680
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35289}
This is somewhat klugey, because it does the same checks at two
different layers in the stack, in different functions, which runs
the risk of making them out of sync. But it solves the immediate
problem.
Bug: chromium:1249753
Change-Id: I2ad96f0cc9499c15540ff6946a409b40df3e3925
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/235826
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35259}
* Replace "AV1X" with "AV1";
* Keep mapping of "AV1X" payload name to kVideoCodecAv1 to not break
support of injectable "AV1X".
Bug: webrtc:13166
Change-Id: I9a50481209209f3857bbf28f4ed529ee6972377e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231560
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34987}
The non-primary SSRC being RTX, for example. Normally a default stream
wouldn't be created from RTX packets, but there is a window of time
where packets can be received before the video engine has receive
parameters/payload type mappings, so it creates one anyway.
Then in AddRecvStream, normally the default stream would be destroyed
before creating a new one, but this only happens for sp.first_ssrc().
Resulting in the error "Receive stream with SSRC 'X' already exists".
Fixed by simply iterating over all SSRCs.
Bug: webrtc:13171
Change-Id: Iaf4e4a3ceafddee3d9b2d1e24af68be56f9695de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/231633
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34971}
Setting the rtp header extensions on the packet delivery thread
(currently worker, soon to be network), is now possible without
taking the hit of deleting and recreating the receive stream (and
rtp receiver and related state).
Bug: webrtc:11993
Change-Id: I9bbe306844a25d85d79cd216092ead66eaf68960
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/223741
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#34953}
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}
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}
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 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}
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}
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}
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}
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}
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}
* 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}
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}
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}
This reverts commit 31c5c9da35209fe65ed15cb3a804823cd2789259.
Reason for revert: made QP parser thread-safe https://webrtc.googlesource.com/src/+/0e42cf703bd111fde235d06d08b02d3a7b02c727
Original change's description:
> Revert "Reland "Enable quality scaling when allowed""
>
> This reverts commit 0021fe77937f386e6021a5451e3b0d78d7950815.
>
> Reason for revert: Broken on linux_tsan bot: https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview
>
> Original change's description:
> > Reland "Enable quality scaling when allowed"
> >
> > This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
> >
> > Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
> >
> > Original change's description:
> > Before this CL quality scaling was conditioned on scaling settings
> > provided by encoder. That should not be a requirement since encoder
> > may not be aware of quality scaling which is a WebRTC feature. In M90
> > chromium HW encoders do not provide scaling settings (chromium:1179020).
> > The default scaling settings provided by these encoders are not correct
> > (b/181537172).
> >
> > This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> > is set to true in singlecast with normal video feed (not screen sharing)
> > mode. If quality scaling is allowed it is enabled no matter whether
> > scaling settings are present in encoder info or not. Setting from
> > QualityScalingExperiment are used in case if not provided by encoder.
> >
> > Bug: chromium:1179020
> > Bug: webrtc:12511
> > Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
> > Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> > Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33438}
>
> TBR=brandtr@webrtc.org,ilnik@webrtc.org,ssilkin@webrtc.org,rubber-stamper@appspot.gserviceaccount.com
>
> Change-Id: Id7633a1e98f95762e81487887f83a0c35f89195c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: chromium:1179020
> Bug: webrtc:12511
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211352
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33439}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I3a31e1c1fdf7da93226f8c1e0a96b43fe0b786df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212026
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33481}
This reverts commit 0021fe77937f386e6021a5451e3b0d78d7950815.
Reason for revert: Broken on linux_tsan bot: https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25329/overview
Original change's description:
> Reland "Enable quality scaling when allowed"
>
> This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
>
> Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
>
> Original change's description:
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020
> Bug: webrtc:12511
> Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33438}
TBR=brandtr@webrtc.org,ilnik@webrtc.org,ssilkin@webrtc.org,rubber-stamper@appspot.gserviceaccount.com
Change-Id: Id7633a1e98f95762e81487887f83a0c35f89195c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1179020
Bug: webrtc:12511
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211352
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33439}
This reverts commit eb449a979bc561a8b256cca434e582f3889375e2.
Reason for revert: Added QP parsing in https://webrtc.googlesource.com/src/+/8639673f0c098efc294a7593fa3bd98e28ab7508
Original change's description:
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I97911fde9005ec25028a640a3f007d12f2bbc2e5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/211349
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33438}
Spec: https://www.w3.org/TR/webrtc-stats/#dom-rtcvideosourcestats-frames
Wiring up the "frames" stats with the cumulative fps counter on the video source.
Tests:
./out/Default/peerconnection_unittests
./out/Default/video_engine_tests
Bug: webrtc:12499
Change-Id: I4103f56ed04cb464f5f7e70fbf2d77c25a867a68
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208782
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33404}
This reverts commit 83be84bb74133343358bba22e4e5106ecc385721.
Reason for revert: Suspect of crbug.com/1185276
Original change's description:
> Reland "Enable quality scaling when allowed"
>
> This reverts commit 609b524dd3ff36719b5c4470b85d37dcdadfb1f8.
>
> Reason for revert: Disable QualityScalingAllowed_QualityScalingEnabled on iOS.
>
> Original change's description:
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020
> Bug: webrtc:12511
> Change-Id: Ia0923e5a62acdfdeb06f9aad5d670be8a0f8d746
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209643
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33385}
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: I7004014c5936176f8c125aeb55da91ce095b266e
TBR: ssilkin@webrtc.org
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209708
Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33393}
This reverts commit 609b524dd3ff36719b5c4470b85d37dcdadfb1f8.
Reason for revert: Disable QualityScalingAllowed_QualityScalingEnabled on iOS.
Original change's description:
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: Ia0923e5a62acdfdeb06f9aad5d670be8a0f8d746
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209643
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33385}
This reverts commit 752cbaba907de077e5f1b24a232e71feb479dccb.
Reason for revert: The test VideoStreamEncoderTest.QualityScalingAllowed_QualityScalingEnabled seems to fail on iOS.
Original change's description:
> Enable quality scaling when allowed
>
> Before this CL quality scaling was conditioned on scaling settings
> provided by encoder. That should not be a requirement since encoder
> may not be aware of quality scaling which is a WebRTC feature. In M90
> chromium HW encoders do not provide scaling settings (chromium:1179020).
> The default scaling settings provided by these encoders are not correct
> (b/181537172).
>
> This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
> is set to true in singlecast with normal video feed (not screen sharing)
> mode. If quality scaling is allowed it is enabled no matter whether
> scaling settings are present in encoder info or not. Setting from
> QualityScalingExperiment are used in case if not provided by encoder.
>
> Bug: chromium:1179020, webrtc:12511
> Change-Id: I83d55319ce4b9f4fb143187ced94a16a778b4de3
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209184
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Åsa Persson <asapersson@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33373}
Bug: chromium:1179020
Bug: webrtc:12511
Change-Id: Icabf2d9a034d359f79491f2c37f1044f17a7445d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209641
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33381}
Before this CL quality scaling was conditioned on scaling settings
provided by encoder. That should not be a requirement since encoder
may not be aware of quality scaling which is a WebRTC feature. In M90
chromium HW encoders do not provide scaling settings (chromium:1179020).
The default scaling settings provided by these encoders are not correct
(b/181537172).
This CL adds is_quality_scaling_allowed to VideoEncoderConfig. The flag
is set to true in singlecast with normal video feed (not screen sharing)
mode. If quality scaling is allowed it is enabled no matter whether
scaling settings are present in encoder info or not. Setting from
QualityScalingExperiment are used in case if not provided by encoder.
Bug: chromium:1179020, webrtc:12511
Change-Id: I83d55319ce4b9f4fb143187ced94a16a778b4de3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/209184
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33373}
Trying to take my first stab at contributing to WebRTC and I chose to populate jitter stats for video RTP streams. Please yell at me if this isn't something I'm not supposed to pick up. Appreciate a review, thanks!
Bug: webrtc:12487
Change-Id: Ifda985e9e20b1d87e4a7268f34ef2e45b1cbefa3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/208360
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33325}
In practice, support for multiple sinks is not needed and supporting
the API that allows for dynamically adding/removing sinks at runtime,
adds to the complexity of the implementation.
This CL removes that Add/Remove methods for secondary sinks as well
as vectors of callback pointers (which were either of size 0 or 1).
Instead, an optional callback pointer is added to the config struct
for VideoReceiveStream, that an implementation can consider to be
const and there's not a need to do thread synchronization for that
pointer for every network packet.
As part of webrtc:11993, this simplifies the work towards keeping
the processing of network packets on the network thread. The secondary
sinks, currently operate on the worker thread.
Bug: webrtc:11993
Change-Id: I10c473e57d3809527a1b689f4352e903a4c78168
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207421
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33272}
This log line adds no value, since the enable state of the feature can
already be deduced from the list of field trials. Instead, this log
line only contributes log spam in calls where `SetRemoteContent` is
called often.
Bug: chromium:1177690
Change-Id: Icafb537de9388df5475919432b3c99f28170e7de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/207428
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33267}
This is a reland of d48a2b14e7545d0a0778df753e062075c044e2a1
The diff of the reland (what caused the tsan error) can be seen
by diffing patch sets 2 and 3. Essentially I missed keeping the calls
to the transport controller on the worker thread. Note to self to add
thread/sequence checks to that code so that we won't have to rely on
tsan :)
Original change's description:
> Prepare to avoid hops to worker for network events.
>
> This moves the thread hop for network events, from BaseChannel and
> into Call. The reason for this is to move the control over those hops
> (including DeliverPacket[Async]) into the same class where the state
> is held that is affected by those hops. Once that's done, we can start
> moving the relevant network state over to the network thread and
> eventually remove the hops.
>
> I'm also adding several TODOs for tracking future steps and give
> developers a heads up.
>
> Bug: webrtc:11993
> Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33138}
Bug: webrtc:11993, webrtc:12430
Change-Id: I4fccaa418d22c2087a55bbb3ddbb25fac3b4dfcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205580
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33153}
This reverts commit d48a2b14e7545d0a0778df753e062075c044e2a1.
Reason for revert: TSan tests started to fail constantly after this CL (it looks like it is flaky and the CQ was lucky to get green). See https://ci.chromium.org/ui/p/webrtc/builders/ci/Linux%20Tsan%20v2/25042/overview.
Original change's description:
> Prepare to avoid hops to worker for network events.
>
> This moves the thread hop for network events, from BaseChannel and
> into Call. The reason for this is to move the control over those hops
> (including DeliverPacket[Async]) into the same class where the state
> is held that is affected by those hops. Once that's done, we can start
> moving the relevant network state over to the network thread and
> eventually remove the hops.
>
> I'm also adding several TODOs for tracking future steps and give
> developers a heads up.
>
> Bug: webrtc:11993
> Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
> Commit-Queue: Tommi <tommi@webrtc.org>
> Reviewed-by: Niels Moller <nisse@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33138}
TBR=nisse@webrtc.org,tommi@webrtc.org
Change-Id: Id87cf9cbcc8ed58e74d755a110f0ef9dd980e298
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: webrtc:11993
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/205525
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33145}
This moves the thread hop for network events, from BaseChannel and
into Call. The reason for this is to move the control over those hops
(including DeliverPacket[Async]) into the same class where the state
is held that is affected by those hops. Once that's done, we can start
moving the relevant network state over to the network thread and
eventually remove the hops.
I'm also adding several TODOs for tracking future steps and give
developers a heads up.
Bug: webrtc:11993
Change-Id: Ice7ee3b5b6893532df52039324293979196d341d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/204800
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33138}
Functionality wise, there should be no change with this CL, aside
from updating tests to anticipate OnPacketReceived to handle the packet
asynchronously (as already was the case via BaseChannel).
This only removes the network->worker hop out of the BaseChannel
class into the WebRTC MediaChannel implementations. However, it updates
the interface contract between BaseChannel and MediaChannel to align
with how we want things to work down the line, i.e. avoid hopping to
the worker thread for every rtp packet.
The following steps will be to update the video and voice channel
classes to call Call::DeliverPacket on the network thread and only
handle unsignalled SSRCs on the worker (exception case).
Bug: webrtc:11993
Change-Id: If0540874444565dc93773aee89d862f3bfc9c502
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/202242
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33040}
Higher range of IDs for peer connection has been exhausted.
Adding AV1 to lower range as it was blocking enabling
libaom by default.
This is blocking crrev.com/c/2617229
Bug: chromium:1095763
Change-Id: If5135122954d00cc03afc563071aec99f145140b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/201523
Commit-Queue: Jerome Jiang <jianj@google.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32967}
It turned out that the negotiated rtp header extensions are not fully known in WebRtcVideoChannel::AddSendStream.
The cl also remove the unnecessary factory for creating VideoStreamEncoder.
Bug: webrtc:12000
Change-Id: If994c8deb69f3ce4212896d3ad757dac94c6e09f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/198840
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32916}
