This reverts commit 45361f78ed.
Reason for revert: Perf alerts galore.
Original change's description:
> Calculate video stream max bitrate using expression.
>
> This replaces the ealier table-based caps.
> Apart from the VGA cap (now 1600kbps instead of 1700kbps), or if using
> "in between" resolutions, the caps are unchanged - but now cover high
> resolutions better.
>
> Bug: webrtc:14017
> Change-Id: I8649b528495d6c917e38ea8cb1a272df6c464c03
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260940
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36776}
Bug: webrtc:14017
Change-Id: I18ebc81c6054713c58d49bd227e37090686958c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261309
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#36794}
This replaces the ealier table-based caps.
Apart from the VGA cap (now 1600kbps instead of 1700kbps), or if using
"in between" resolutions, the caps are unchanged - but now cover high
resolutions better.
Bug: webrtc:14017
Change-Id: I8649b528495d6c917e38ea8cb1a272df6c464c03
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260940
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36776}
convert almost all of video/ (and the collateral)
Bug: webrtc:10335
Change-Id: Ic94e05937f54d11ee8a635b6b66fd146962d9f11
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/254601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36192}
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}
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}
The test could cause a UAF as the test exits while the lambda is
still running. Only seems to happen on Linux for some reason.
Bug: webrtc:12854
Change-Id: Ie0c0de09b675ef93dc195a6470752a772083029e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/238425
Auto-Submit: Markus Handell <handellm@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#35389}
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 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}
Setting different number of temporal layers is supported by SimulcastEncodeAdapter and LibvpxVp8Encoder will fallback to SimulcastEncoderAdapter if InitEncode fails.
Bug: none
Change-Id: I8a09ee1e6c70a0006317957c0802d019a0d28ca2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/228642
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#34785}
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}
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 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 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}
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}
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 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}
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}
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}
This reverts commit 31c5c9da35.
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 0021fe7793.
>
> 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 eb449a979b.
> >
> > 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 0021fe7793.
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 eb449a979b.
>
> 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 eb449a979b.
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}
This reverts commit 83be84bb74.
Reason for revert: Suspect of crbug.com/1185276
Original change's description:
> Reland "Enable quality scaling when allowed"
>
> This reverts commit 609b524dd3.
>
> 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 609b524dd3.
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 752cbaba90.
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}
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}
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}
This is a reland of f08db1be94
Original change's description:
> Enable FlexFEC as a receiver video codec by default
>
> - Add Flex FEC format as default supported receive codec
> - Disallow advertising FlexFEC as video sender codec by default until implementation is complete
> - Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
>
> Bug: webrtc:8151
> Change-Id: Iff367119263496fb335500e96641669654b45834
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
> Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Ying Wang <yinwa@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32639}
Bug: webrtc:8151
Change-Id: I36cbe833dc2131d72f1d7e8f96d058d0caa94ff9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195363
Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32819}
Changes the video payload type allocation to use the
lower dynamic payload type range [35,65] described in
https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml#rtp-parameters-1
for new codecs such as FlexFEC.
BUG=webrtc:12194
Change-Id: I71782199074e0fc94fa6aa8c36afeb68221a2839
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195822
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32799}
Without this change, if the user disables QVGA and VGA streams via |active|
flags in SetParamters, the resulting stream would have too high min bitrate.
This would lead to bad performance and low quality adaptation rate.
Bug: none
Change-Id: I919a30bfb248c06747c989afe6965b3afaef2260
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/195325
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32706}
This reverts commit f08db1be94.
Reason for revert: It looks like this breaks Chromium FYI Windows bots.
See https://ci.chromium.org/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20Win10%20Tester/6988.
If this is not the culprit I will reland.
Original change's description:
> Enable FlexFEC as a receiver video codec by default
>
> - Add Flex FEC format as default supported receive codec
> - Disallow advertising FlexFEC as video sender codec by default until implementation is complete
> - Toggle field trial "WebRTC-FlexFEC-03-Advertised"s behavior for receiver to use as kill-switch to prevent codec advertising
>
> Bug: webrtc:8151
> Change-Id: Iff367119263496fb335500e96641669654b45834
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/191947
> Commit-Queue: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Ying Wang <yinwa@webrtc.org>
> Reviewed-by: Christoffer Rodbro <crodbro@webrtc.org>
> Reviewed-by: Stefan Holmer <stefan@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#32639}
TBR=brandtr@webrtc.org,tommi@webrtc.org,stefan@webrtc.org,crodbro@webrtc.org,crodbro@google.com,yinwa@webrtc.org,philipp.hancke@googlemail.com,hmaniar@nvidia.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:8151
Change-Id: Ia1788a1cf34e0fc9500a081552f6ed03d0995d5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/194334
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#32657}
