This removes the unused field trials
`WebRTC-SimulcastScreenshareUpswitchHysteresisPercent` and
`WebRTC-SimulcastScreenshareUpswitchHysteresisPercent` as well as the
`video_hysteresis` and `screenshare_hysteresis` parameters in
`WebRTC-VideoRateControl`.
The hysteresis parameters in `WebRTC-StableTargetRate` are currently
left, their future is unclear...
Bug: webrtc:9734
Change-Id: I9e6bbe4b630a0501d365bf69e87e65164c500122
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269207
Reviewed-by: Emil Lundmark <lndmrk@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37635}
From when callTest's send_transport_ is deleted and until the test is
completely ended, there is a possibility that the background task
webrtc::ModuleRtpRtcpImpl2::MaybeSendRtcpAtOrAfterTimestamp
will call send_transport_ which has already been deleted.
Fix this by deleting rtp_rtcp_ before send_transport_ is deleted.
Bug: webrtc:14202
Change-Id: Ief96c4712875beb55ef232a8bce990d1e9e9efe1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266300
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Daniel.L (Byoungchan) Lee <daniel.l@hpcnt.com>
Cr-Commit-Position: refs/heads/main@{#37633}
instead of using Lock/Unlock attributes, use Assert attribute to annotate code is running on certain task queue or thread.
Such check better matches what is checked, in particular allows to
recheck (and thus better document) currently used task queue
Bug: None
Change-Id: I5bc1c397efbc8342cf7915093b578bb015c85651
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269381
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37619}
Fix call in FrameBuffer3Proxy to OnDecodableFrameTimeout to match with
FrameBuffer2Proxy and how OnEncodedFrame is called.
Bug: none
Change-Id: I6f5f18bd9a425aa55f5826654b24c2c0ee5af5f7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269302
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37610}
Using 4 temporal layers is not quite supported: Not advertised, no
integration tests. When transitioning to configuration via scalability
mode, there are no corresponding modes defined. So delete these two
tests; they can be added back if/when support for corresponding
scalability modes are added.
Bug: webrtc:11607
Change-Id: I97f55dc95d6513ccf65fa887757a62e9c8659be7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269003
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37575}
rtc::TaskQueue is a simple wrapper over TaskQueueBase and adds no
extra features when task queue is used without passing ownership.
Reducing usage of the internal rtc::TaskQueue wrapper gives users more flexibility how TaskQueueBase* is stored.
Bug: webrtc:14169
Change-Id: If5c8827544c843502c7dfcef775ac558de79ec3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268189
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37549}
SetFeedbackParameters no longer recreates the embedded streams for:
- transport cc flag
- rtcp status
Bug: none
Change-Id: If6117a1ae760ca9a02f06bbfa2b46c6e0f448cfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268281
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37526}
The decode time per frame and codec profile histograms were added
temporarily to make it possible to get an overview of the decode
time distributions. This fine grained information is not needed
longer and the histograms can be deleted.
Bug: chromium:1007526
Change-Id: Ie59627a88813e0710700cf0e13eedd6627010266
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266496
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37316}
This was capped to the max wait for a frame, but if the stream was
timing out in a set period of time, it would do this before the frame
was decoded. Instead, this should be done the stream timeout is
triggered.
Bug: webrtc:14168
Change-Id: Iecde082bd223c469f735afeb77a00c0387e47b3b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266369
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37310}
increasing precision since summing up rounded values leads to
a rounding error, in particular for small frames which take very
little time to decode.
BUG=webrtc:12526,webrtc:13756
Change-Id: I647c702808856a002c746ed9f115aa9bcaddc1f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262810
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/main@{#37249}
Last attempt resulted in some regressions in low-bw scenarios. These
should have been fixed with bugs.webrtc.org/14168.
Bug: webrtc:14003
Change-Id: Iaab954b7f9a390fbfc96a9cf0dacb3a950157c49
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265865
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37240}
This CL accomplishes three things:
1) It enables feeding frame drop indications into the
AdaptedVideoTrackSource for the benefit of downstream projects.
2) Under zero hertz source delivery, a discarded frame ending a
sequence of frames which happened to contain important information
can be seen as a capture freeze. Avoid this by starting requesting
refresh frames after a grace period.
3) It changes the duration until first refresh frame requests on new
streams to three frame periods.
Bug: chromium:1324120, chromium:1336952
Change-Id: I0214852f1a26540588f6c193dd88a65c34ec0d99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265871
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37238}
This will later be used when merging FrameBuffer3Proxy into
VideoReceiveStream2.
Bug: webrtc:14003
Change-Id: Ieb97767c40f494510873abe775fc339125036dc0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265923
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37237}
This is the first CL out of three to make the low-latency stream signaling
explicit. At the moment this is done by setting the render time to 0.
There's a dependency between Chromium and WebRTC which is why this is
split into three CLs to not break any existing functionality.
Bug: chromium:1327251
Change-Id: Ie6b268746d587a99334485db77181fb2c6e9b567
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264502
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37225}
This is cleaner than checking the size before and after, as is currently
done in FrameBufferProxy
Bug: webrtc:14168
Change-Id: Iac896ddf7b1b0b8513159451de7cd8a10668a49a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265663
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37222}
In FrameBuffer3Proxy, if the stream became undecodable for a long
period of time and during this period the FPS changed,
the render times and decode delays would stray and cause
video pauses. This was because FrameBuffer3Proxy only updated the rtp
timestamp extrapolator on each new decodable temporal unit, rather than
each new frame.
Bug: webrtc:14168
Change-Id: I67a2c9ea392d24f84e82aa04f8c3076de11732af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265388
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37201}
When a large queue of frames builds up due to a lost frame, the decode
delay can sometimes become quite large. In this case the stream may
signal as timed out when in fact it is not. Instead, the delay should
be capped at the timeout limit.
Bug: webrtc:14168
Change-Id: I5b4e8851b2c6d7d27a698627dc1633931d7fc00e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265404
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37199}
This cl/ adds a way of setting an EncoderSelector on a specific
RtpSenderInterface. This makes it possible to easily use different
EncoderSelector on different streams within the same or different PeerConnections.
The cl/ is almost identical to the impl. of RtpSenderInterface::SetFrameEncryptor.
Iff a EncoderSelector is set on the RtpSender, it will take precedence
over the VideoEncoderFactory::GetEncoderSelector.
Bug: webrtc:14122
Change-Id: Ief4f7c06df7f1ef4ce3245de304a48e9de0ad587
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264542
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37150}
FrameBuffer3Proxy and sync decoding has been shown to work. First step of cleaning up is to remove the FrameBuffer2Proxy.
Change-Id: Ic96303c2d4f9111cfeed9927e8826ea7ffe7ee17
Bug: webrtc:14003
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264126
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37086}
Code that is probably bogus and causes frequent down-adaptation on
dual core systems was identified. We wish to remove this code in a
safe way. This CL achieves this under kill switch
WebRTC-MacSpecialOveruseRulesRemovalKillSwitch.
Fixed: webrtc:14138
Change-Id: Idf53348c8e1dc032d8eea58f626f91456d72ecb4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264423
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Auto-Submit: Markus Handell <handellm@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37043}
Setting the transport cc flag was only possible post creation for
audio receive streams, while video receive streams need to be recreated.
This CL moves the setter for transport_cc() to where the getter is and
adds boiler plate implementations for the video streams. For audio
streams this splits "SetUseTransportCcAndNackHistory" into two methods,
SetTransportCc and SetNackHistory.
Bug: none
Change-Id: Idbec8217aef10ee77907cebaecdc27b4b0fb18e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264443
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37038}
