This gives the option to synchronize rendering updates with
the display refresh cycle and limit effective updates to a certain frame
rate.
go/meet-android-synchronized-rendering
Bug: b/217863437
Change-Id: I4938a10f4e80d98a17e28f2e397fbb95117a3e4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325061
Reviewed-by: Ranveer Aggarwal <ranvr@webrtc.org>
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41012}
Using RTC_DCHECK for test validation is wrong to begin with (gets
compiled out in non-debug builds, which measn we may miss validations),
but becomes extra problematic when we include code with side-effects
inside the DCHECK, which results in release-build tests having a
different flow than intended
Bug: webrtc:15572
Change-Id: I89d5b55f903b9d93fe4a929548d1b9fcde8941be
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323182
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41005}
RenderSynchronizer is used to coordinate video rendering updates
to a specific frame rate target and aligned to display refresh cycles.
go/meet-android-synchronized-rendering
Bug: b/217863437
Change-Id: Ie329c4c2eccfb0c9aee9b90f7ddbc370919d5e86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324840
Reviewed-by: Ranveer Aggarwal <ranvr@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Linus Nilsson <lnilsson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41004}
Calls the AudioOutput implementation of GetStats, which is currently
not implemented.
Bug: webrtc:14653
Change-Id: Ieaf0e0c030a95d23c8950ff9038a64426142a789
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324800
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41003}
Parses log, calls analyzer and populates output.
Currently only outputs two charts. Chart selection to be added in a followup.
Bug: None
Change-Id: I960cff15a5935a638a5d979a71230ad598083596
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324680
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Auto-Submit: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41000}
showing that putting attribute lines before time information in the
session part is rejected and that unknown attribute lines do not
cause parsing errors
BUG=webrtc:15597
Change-Id: I291ee3d7d6c25ca63c86c1b4a92feb9083be408f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324621
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#40999}
kDefaultQpMax=56 was defined in multiple places. Move it to media_constants and split it into two: VPx/AV1 and H26x values. H26x value is set to 51 which is the max bitstream QP value for H264/5.
This CL is expected to be a no-op because:
1. VideoCodec::qpMax value has not changed for VP8/9 and AV1.
2. VideoCodec::qpMax is currently not used by OpenH264 wrapper (wiring it up is out-of-scope of this CL).
3. Previous default qpMax=56 exceeded the max value for H26x (=51). External HW H26x encoders likely clamped it and used 51.
Bug: webrtc:14852
Change-Id: I1d795e695dac5c78e86ed829b24281e61066f668
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324282
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40997}
Bug: webrtc:1314868
Change-Id: Ia743d17d61d7d8ffc44030b5691efef1c7ed7991
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324305
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40994}
Before this change bitrate limits for VP9 single spatial layer case were set in VideoCodecInitializer. Move this logic to GetVp9SvcConfig. This simplifies replication of WebRTC behaviour in codec level tests. The similar AV1 logic sits in SetAv1SvcConfig, not VideoCodecInitializer.
Bug: webrtc:14852
Change-Id: Ie7202ec880d0e4b903e7265721eeef9b3920f21a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324286
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40992}
The initial hold duration is 300ms.
Whenever it enters kDecreasing state, it will double the current hold duration. The hold duration will be reset as soon as the delay based estimate works, e.g. the state is kDelayBased to avoid getting stuck at low bitrate.
Bug: webrtc:12707
Change-Id: I3906ff80b071ba3eb6274b012fb31922f4cbc7b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324304
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40991}
This is currently a stub. The analysis will be added in a followup CL.
No-Try: True
Bug: None
Change-Id: Ief381d0c30ec29a0ef170523d31f1f902d0e6b09
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324620
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40989}
Someone wondered why framesRendered has not been implemented. I had a
look, and discovered that a) we need to implement it, and b) our entire
inter-frame, pause, and freeze metrics are measured at the wrong time
because what WebRTC considered "OnRenderedFrame()" is not actually when
the frame was rendered.
So that we don't forget this again, I filed two crbugs and added TODOs
in the code for future reference to anyone interested in these metrics.
Bug: webrtc:15600, webrtc:15601
Change-Id: Id38df7874df715e9b9c0410efa4a9bc2af5d6232
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324306
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40987}
Addes field trial UpperBoundCandidateInAlr to LossBasedBweV2. If an
instant upper bound exist in ALR that are lower than current estimate,
use it as a candidate.
Bug: webrtc:12707
Change-Id: I55595c7225c4289e1bc4edde9d9576e0443d3dce
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324220
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40986}
This moves steps from the sdp code for pc state over to the PC class
and slightly simplifies the contract between the two classes.
Moving forward it's easier to consolidate those steps in the PC
class with other grouped operations e.g. during teardown.
Also removing GetDataMid() method in favor of the sctp_mid() property.
Bug: none
Change-Id: I938f953099d327377abd94e6b2c9ece803d88e40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324300
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40981}
UsePadding - signals to GoogCC that padding should be used to fill up to
BWE while BWE is ramping up.
Bug: webrtc:12707
Change-Id: I7b4922dff3a83da370c50c567050bfa748190b40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324160
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40979}
Ensure acked bitrate is not used for lower loss based estimate if
estimate improve.
Ensure LossBasedBweV2 is in state DelayBased if reached max rate.
Bug: webrtc:12707
Change-Id: I20230b99e0c2b530570e2f2de8ea88179f795c50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324140
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40977}
Expect OnNetworkAvailabability to be invoked when the transport becomes writable.
Before this change, ProbeController in GoogCC was expected to be created when the transport is writable or explicitly notifed after creation that network is not writable.
Bug: None
Change-Id: I623b1c34e40a82e912f85b92fea49629e7e72d4e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323463
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40975}
Sometimes OpenH264 returns a key frame even though we have not
requested one. However, SVC controller does not know about this
and will not reset its state. Since we are comparing expected tid
from SVC controller with actual tid from OpenH264, and drop frames
if they do not match, that causes a missing frame.
This CL resets the SVC controller state on key frames, ensuring
that it accurately maintains its state and does not drop frames.
Also, changes the message of the error log to be more descriptive.
Now, it will print the expected tid and actual tid.
Bug: webrtc:14877
Change-Id: I6c9e7532b2478773f03e5707bf7a1ca56e4f7b99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324001
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40972}
Without this change a FrameDropped sample will be added to
WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult at the
current capture rate as long as a captured window is minimized.
Bug: webrtc:1314868
Change-Id: I9b68675486642e7ca25674df689c207ac94a206e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323882
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#40969}
The state should be computed from the actual estimate rather than the best estimate candidate. The fix is NOT under field trial.
And some other cleanup:
1. Loss based result will be computed in UpdateBandwidthEstimate method. Currently it is re-computed in GetLossBasedResult.
2. Rename current_estimate to current_best_estimate to avoid misunderstanding that current_estimate is the `final estimate`. The final estimate is computed by applying lower and upper bound on current_best_estimate
3. Remove current_state_. The state is stored directly in loss_based_result_.
Bug: webrtc:12707
Change-Id: Ie612845f907b9e6333fbd8249ddc9b93ad9f8042
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324022
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40964}
In some very high-bandwidth application there have been observations of
packet loss in the socket implementation (not on the network itself) due
to large bursts of packets arriving. Allocating too big buffers can of
course lead to issue as well, so this flag is intended to find a good
tradeoff.
Bug: webrtc:15585
Change-Id: I63eccb1a9f34d852d80c286fc27bffd17818f0ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324021
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40963}
