that rtc::Location parameter was used only as extra information for the
RTC_CHECKs directly in the function, thus call stack of the crash should
provide all the information about the caller.
Bug: webrtc:11318
Change-Id: Iec6dd2c5de547f3e1601647a614be7ce57a55734
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270920
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37748}
Resolves an issue where, in Chrome, WebRTC event logs do not capture outgoing packets for video receivers because no reference to the event log was passed to the video receiver.
Bug: webrtc:14338
Change-Id: Ia33ce6f2d69a0e341530648b10a08516dc53abf3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271080
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37746}
This behaviour has been fixed with the introduction of FrameBuffer3
Bug: webrtc:14033, webrtc:13343, webrtc:9974
Change-Id: Iba81c169706336e85194ed141324466e44a2c859
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265867
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37742}
The data that's used to report the histograms is owned by UlpfecReceiver
and moving the reporting there, simplifies things as configuration
changes happen in RtpVideoStreamReceiver2 (which currently require all
receive streams to be deleted+reconstructed).
Additional updates:
* Consistently using `Clock` for timestamps. Before there was
a mix of Clock and rtc::TimeMillis.
* Update code to use Timestamp and TimeDelta.
Bug: none
Change-Id: I89ca28ec7067a49d6b357315ae733b04e7c5a2e3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271027
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37729}
We only need to see which bitrates have been configured, no need to
wait for failed frame. This should also reduce test durations somewhat.
Bug: None
Change-Id: Ie081310f9f80e21039c78d8c80510769cb400c3a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270747
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37711}
This replaces use of RunLoop and SimulatedClock. As a related change,
units like TimeDelta and Frequency are used as needed.
Bug: None
Change-Id: I892ee38641f2fd37d4bd1b0fb425bfb5d4706ac1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270626
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37708}
This allows for `config_.rtp.nack.rtp_history_ms` to be modified
without deleting and recreating video receive streams.
Bug: webrtc:11993
Change-Id: I8ba132b22fe0e6de03d1c42fc38a570cbe138817
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269301
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37701}
...to allow for turning on/off loss notifications for video receive
streams without tearing down and recreating the whole stream.
Bug: webrtc:11993
Change-Id: Ia961bd343ce816ffe3414f11e3a58bb3c235307c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269252
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37688}
follow-up from https://webrtc-review.googlesource.com/c/src/+/262810
* replace Time::Millis(0) and TimeDelta::Millis(0) with ::Zero()
* drop unnecessary webrtc namespace from some TimeDeltas
* make TimeDelta do the unit conversion for stats
BUG=webrtc:13756
Change-Id: Ic60625ae0fc7959a47a6be9f5051851feaf76373
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265875
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37664}
If a "normal" software buffer frame is dropped during paused state, we
store it as a pending frame and try encoding it after the pause state is
lifted. However, native frames are dropped entirely since keeping e.g.
texture handles for long time periods can lead to side effects.
Work around this by requesting a refresh frame after unpausing if the
dropped frame flag is set.
Bug: webrtc:14276
Change-Id: I9edd1e99454e082bcfe29f3d9041026dd8a390d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270220
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37660}
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}
