This collision can occur when we have
asymetrical send and receive codecs. This is the case in the current
code base with the VP9 codec familly but is not visible untill more
codecs are added.
Added Nutanix Inc. to AUTHORS.
Bug: chromium:1291956
Change-Id: I09d3f76161d984d2a3edf721639753bffd4947b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250034
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35944}
Currently if encoder initialization fails WebRTC doesn't send any video.
This CL adds functionality that changes encoder type in such case and
restores the video. If encoder selector is available we switch to
encoder it recommends. Otherwise, VP8 is used as the default fallback
encoder.
Bug: webrtc:13572
Change-Id: Ifcdf707a575711f5ff81f9451caf30140c9171dc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246960
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35761}
WebRTC can switch encoder on-fly when encoder fails or by request from
encoder selector. Putting the current send codec to the front of the
codecs list provides a simple way for apps to know what is actually
used without retrieving stats.
Bug: webrtc:13572
Change-Id: Iaaa5f7ad8667f59016dc92bff9e9a57a7425ef44
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/246500
Reviewed-by: Mirta Dvornicic <mirtad@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35723}
Because of this (seemingly simple) change, I had to change the return
type of transport_name from `const std::string&` to `absl::string_view`
to handle the case when there's no transport assigned.
That in turn caused an avalanche of required updates.
Bug: webrtc:12230, webrtc:11993
Change-Id: I16ec6c6a5fc2f5f7c7de572355a3c6ca924bb9d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244084
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35617}
This makes things slightly simpler for the time being as surrounding
code is being refactored. This also removes a PostTask which has the
effect of shrinking the window between the Pending/Complete
notifications slightly since there's no additional async task
for the 'complete' step.
Bug: webrtc:11993
Change-Id: Ia86779b21c6f87301f37d763f89ace722e06e563
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/244081
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35609}
Removes a few constructors where similar ones existed.
Removes MediaConfig dependency from MediaChannel and fixes an iwyu.
Bug: none
Change-Id: I9e34a1da0852c3fb21222161fad315e70598db3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242966
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35608}
Legacy code depended of setting VideoCodecVP8::frameDroppingOn to false
for screensharing since the reference frame management handles frame
dropping in the VP8 wrapper instead.
Now the frame dropping is instead configured based on what the
Vp8FrameBufferController instance in use signals.
This change unblocks relanding
https://webrtc-review.googlesource.com/c/src/+/242366
This CL also turns frame dropping on for H264 screenshare, which
should be desirable as it allows for quicker recovery from rate control
overshoots.
Bug: webrtc:9734
Change-Id: I34a29edcd41bb5fd07f7f9bf68660472a1570533
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/242965
Reviewed-by: Markus Handell <handellm@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35592}
Some screen capturers may occasionally send an extremely small frame,
e.g. 2x2. If a scale_resolution_down_by is specified, WebrtcVideoEngine
would enforce configured resolution to be at least 16x16, which would
then break VideoStreamEncoder and cause a crash.
This changes disables scaling and alignment for extremely low resolutions.
Bug: chromium:1265303, webrtc:13371
Change-Id: Icdb736043e1fdf91fdde5a8e4b3c6a89f6b90577
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/236850
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35420}
This change moves the responsibility of posting
EncoderSwitchRequestCallback calls closer to the top-level
users which has a better idea about threading requirements.
The change is planned to be followed-up with more changes removing
the need for VSE to post to the worker thread.
Bug: webrtc:13414, chromium:1255737
Change-Id: I57a2962a70e9f245460c59c0d61824371394b952
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238420
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35387}
Instead use `parameters_.config.rtp.ssrcs.size()` directly to make decisions about the number of temporal and spatial layer used.
Bug: none
Change-Id: Icba553178ae7fea281c2c67654c510228d9ab5b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/237080
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35299}
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}
