PacingController per default use a burst interval of 40ms. The behaviour can still be overriden by using the method SetSendBurstInterval.
Bug: chromium:1354491
Change-Id: Ie3513109e88e9832dff47380c482ed6d943a2f2b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/311102
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41254}
This means that RtpPacketHistory::PaddingMode::kRecentLargePacket is
used per default.
Bug: webrtc:15201, b/284281602
Change-Id: If8feb66105a9b1e13ae4cb28a44a74c8839b72e1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327602
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41215}
There are two threads involved here, the thread that calls the API
functions and the pipwire main loop. Using one race checker for both is
wrong and triggers aborts.
Use a different race checker for all variables that are used by the
pipewire main loop or guarded against concurrent access with the
thread_loop_lock.
In one case, two RTC_CHECK_RUNS_SERIALIZED() checks are needed, so
enhance the macro to generate unique variable names.
Bug: webrtc:15181
Change-Id: Ib41514eb7aa98fe85d830461aa0c71e42ba821bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326781
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41198}
This ensure upper link capacity estimate upper limit an increase in
delay based estimate, but the delay based estimate is not decreased if
link capacity estimate decrease.
Bug: webrtc:10498, b/300868877
Change-Id: I87e76e2a869e6f721cc8fe9d422e0194371d4e45
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327801
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41196}
This is a reland of commit 496893e89e5bc8139e50befcb1a26eadbd829b0d
Original change's description:
> Added an encode/decode test parameterizable via command line
>
> This enables testing different settings without updating code and rebuilding the test binary. Example of command:
>
> video_codec_perf_tests --gtest_also_run_disabled_tests --gtest_filter=*EncodeDecode --encoder=libaom-av1 --decoder=dav1d --scalability_mode=L1T3 --bitrate_kbps=100,200,300 --framerate_fps=30 --write_csv
>
> Also added writing per-frame stats to a CSV. It is more convenient to work with CSV than to parse metrics proto.
>
> Bug: webrtc:14852
> Change-Id: I1b3970f7ffa88c016133197aff585de5bc4e35c6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327600
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41179}
Bug: webrtc:14852
Change-Id: Iccb9af8bf6a6c37704bc58b6e57238b55761b079
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327781
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41194}
Add a StartShortCircuiting() callback to allow clients which have
configured Encoded Transforms when creating a PeerConnection to have
all frames skip the transform. This offers a zero cost path for streams
which don't need transforms.
This is preferable to uninstalling/not installing the transform to allow
implementing the behaviour in
https://w3c.github.io/webrtc-encoded-transform/#stream-creation -
giving web apps a chance to configure transforms within a short window
(before the next JS event loop run, so usually sub-millisecond) after stream creation, without any untransformed frames passing.
Usage in Chromium: crrev.com/c/5040731
Bug: chromium:1502781
Change-Id: I803477db1df51e80bdedf6c84d2d3695b088de83
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327601
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Cr-Commit-Position: refs/heads/main@{#41184}
This reverts commit 496893e89e5bc8139e50befcb1a26eadbd829b0d.
Reason for revert: Breaks https://ci.chromium.org/ui/p/chromium/builders/webrtc.fyi/WebRTC%20Chromium%20FYI%20ios-device/16103/overview
Original change's description:
> Added an encode/decode test parameterizable via command line
>
> This enables testing different settings without updating code and rebuilding the test binary. Example of command:
>
> video_codec_perf_tests --gtest_also_run_disabled_tests --gtest_filter=*EncodeDecode --encoder=libaom-av1 --decoder=dav1d --scalability_mode=L1T3 --bitrate_kbps=100,200,300 --framerate_fps=30 --write_csv
>
> Also added writing per-frame stats to a CSV. It is more convenient to work with CSV than to parse metrics proto.
>
> Bug: webrtc:14852
> Change-Id: I1b3970f7ffa88c016133197aff585de5bc4e35c6
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327600
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41179}
Bug: webrtc:14852
Change-Id: Ifdce738058c3e3fc7c76886939add2813405cae7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327722
Owners-Override: Christoffer Jansson <jansson@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Christoffer Jansson <jansson@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#41183}
This enables testing different settings without updating code and rebuilding the test binary. Example of command:
video_codec_perf_tests --gtest_also_run_disabled_tests --gtest_filter=*EncodeDecode --encoder=libaom-av1 --decoder=dav1d --scalability_mode=L1T3 --bitrate_kbps=100,200,300 --framerate_fps=30 --write_csv
Also added writing per-frame stats to a CSV. It is more convenient to work with CSV than to parse metrics proto.
Bug: webrtc:14852
Change-Id: I1b3970f7ffa88c016133197aff585de5bc4e35c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327600
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41179}
The updated Flexfec RFC states that a kbit of "0" means this is the last block of the mask, whereas in the 03 draft, "0" meant there's another block.
Reversing the logic in the updated RFC parser to fix.
Bug: webrtc:15002
Change-Id: I40e4c950b09ddf2db9da6c01908737282161bf1c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327580
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41174}
Make sure the notifier is reset when tearing down the camera portal and also when we already called it. Destruction of camera portal will be mostly invoked by an object holding it and serving as an implementation of the notifier interface and in such case we have to make sure it will
not get called at this moment.
Bug: webrtc:15407
Change-Id: If0c1fb1493d64d5e1f0228ed71813abbb9280083
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/315420
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41167}
Moving the header file and definitions for PipeWireSession to the source
file allows DeviceInfoPipeWire to be reimplemented or used in wrappers
without the consumer needing to add PipeWire includes and definitions.
Bug: webrtc:15654
Change-Id: I895059d50bdf9e6ed152eca729c618261701457a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327381
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Cr-Commit-Position: refs/heads/main@{#41163}
* Pass codec factories to the video codec tester instead of creating and wrapping codecs into a tester-specific wrappers in video_codec_test.cc. The motivation for this change is to simplify the tests by moving complexity to the tester.
* Merge codec stats and analysis into the tester and move the tester. The merge fixes circular deps issues. Modularization is not strictly needed for testing framework like the video codec tester. It is still possible to unit test underlaying modules with rather small overhead.
* Move the video codec tester from api/ to test/. test/ is accessible from outside of WebRTC which enables reusing the tester in downstream projects.
Test output ~matches before and after this refactoring. There is a small difference that is caused by changes in qpMax: 63 -> 56 (kDefaultVideoMaxQpVpx). 56 is what WebRTC uses by default for VPx/AV1 encoders.
Bug: webrtc:14852
Change-Id: I762707b7144fcff870119ad741ebe7091ea109ba
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/327260
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41144}
- Stable delay mode: this results in a very large reduction in the amount of time stretching and fewer underruns.
- More closely align PLC and CNG logic.
- Stop playing comfort noise after a timeout when no packets are received.
Several tests needed to be updated to match the new behavior.
Note that I should also refactor GetDecision to be easier to test in the future (remove internal state).
Bug: webrtc:13322
Change-Id: I1724a74b3b583d05a4bb8feb4f9a8c4a8b2b7c5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326780
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41125}
std::is_pod is deprecated since C++20. Replace with std::trivial and
std::is_standard_layout. Avoids a lot of warnings.
Bug: chromium:957519
Change-Id: Idb4bde7401c14c0896a84c357ec668b9916f613e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325484
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41117}
It did not result in big quality improvements.
Bug: webrtc:12201
Change-Id: I9728469a388ee179d6069af8521bfc5571870bd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325533
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41087}
This CL is a follow-up of work done in
https://webrtc-review.googlesource.com/c/src/+/323882 where the goal
was to reduce the amount of FrameDropped error logs in
WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult.
The previous work avoids FrameDropped logs for a minimized window
being captured with WGC but we still se a large amount of these error
(or rather warning) logs. See [1] which comes from Canary.
This CL does two different things to improve the situation:
1) It adds kFramePoolEmpty to the existing
GetFrameResult::kFrameDropped enum to point out that the warning
comes from the frame pool not being able to return a valid new frame.
It also makes it more clear that it does not cause an outer/final
error as WgcCapturerResult::kFrameDropped. We still keep the inner
GetFrameResult::kFrameDropped but it is only produced when the frame
pool returns NULL and our external queue is empty. Hence, a real
frame-drop error. Note that, it is still easy to provoke
kFramePoolEmpty simply by asking for a high resolution at a high rate.
The example in [2] comes from a 4K screen @30fps. Hence, we have not
fixed anything yet.
2) It also increases the size of the internal frame pool from 1 to 2.
This does lead to an almost zero rate of kFramePoolEmpt
warnings at the expense of a slightly reduced max capture rate. BUT,
with 1 as size, we can "see" a higher max capture rate but it is not
a true rate since it comes with a high rate of kFramePoolEmpty
errors. Hence, we "emulate" a high capture rate by simply feeding
copies of the last frame that we had stored in the external queue.
Using 2 leads to a more "true" rate of what we actually can capture
in terms of *new* frames and also a substantially lower rate of
kFramePoolEmpty.
In addition, with 1 as size, if we ask at a too high rate and provide
a copy of the last frame, our CPU adaptation will not reduce its rate
since we think that things are OK when it is actually not.
Also, the samples in [3] and [4] both use 2 as numberOfBuffers
as well.
Let me also mention that with this small change, I a have not been
able to provoke any kFramePoolEmpty error messages.
Finally, geDisplayMedia can be called called with constraints where
min and max framerate is defined. The mechanism which maintains the
min rate is implemented via the RequestRefreshFrame API and it can
be sent to the source (DesktopCaptureDevice) back to back with a
previous timer interrupt for a capture request. Without this change,
these RRFs were also a source of a large amount of
kFramePoolEmpty error logs. With 2 buffers instead; this is no
longer the case.
[1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj
[2] https://paste.googleplex.com/4795680001359872
[3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp
[4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability
Bug: chromium:1314868
Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521
Commit-Queue: Alexander Cooper <alcooper@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Cr-Commit-Position: refs/heads/main@{#41079}
To ensure padding, we increase 1 bit instead of 1kbps to avoid that 1kbps adds up over time.
Not have unit test for this, but did manual/hamrit tests many times.
Bug: webrtc:12707
Change-Id: I9b3160ab1808cb3a21ff0609446359a4ec3a4949
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325520
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41056}
The change is under field trial use_in_start_phase.
Bug: webrtc:12707
Change-Id: I2ba8245c5d126b3c8a2e54b826853d98aad6e4f9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325184
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41047}
Increasing BWE by 1kbps should be safe/no-op in practice, and it ensures that padding in kIncreasing state will be triggered.
Bug: webrtc:12707
Change-Id: I82493d07a80abd60c93d9cff74baf0a55e77f2b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325286
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41046}
Removed thread safety: for a low level helper it adds overhead that users may not need. In particular RtpSenderVideo doesn't need it because calls to SendVideo are already synchronized.
Added a feature to force producing extension as requested by downstream.
Cleanup and document api:
Changed rtp_frequency type to int as it has no reason to use uint32_t per style guide
Changed absolute_capture_time to NtpTime to clarify both units and offset of the time. NtpTime has trivial conversion to/from uint64_t
Documented all the parameters.
Cleanup tests.
Bug: b/307553606
Change-Id: I0922ca4d3c89f124eeb561742dca79ed5c2327fd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325022
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Chen Xing <chxg@google.com>
Cr-Commit-Position: refs/heads/main@{#41023}
If we have been sending padding for 1s and estimate still is unchanged, then stop padding by transitioning to decrease state.
Bug: webrtc:12707
Change-Id: I0dca2e5cd98263fc7fae9882c23c21634413c7a0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324740
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41018}
Reasons:
- the code is no longer used in Chrome
- it is conceptually weird for WebRTC to have JSON parsing in its API
- there are concerns around the reliability of the underlying JSON library
Additionally, this CL removes the rtc_json "poisonous" attribute: the scheme is incompatible and redundant with testonly.
Bug: webrtc:1493351
Change-Id: I0b621b0e3f183df7315919d9c89242fbe387928f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325062
Reviewed-by: Per Åhgren <peah@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41014}
2 main reasons:
1. Packet sizes are much different thus a lost audio packet should not be treated similar to a lost video packet. In low bandwidth/traffic policing scenario, the number of send packet is few, thus the computed loss can be imprecise.
2. Given a candidate bandwidth estimate, the objective function (how good the candidate is) is computed by recomputing loss rate = send rate/estimate bandwith + inherent loss. It means the objective function is byte based rather than packet based.
Potential risk: the current algorithm params are tuned based on packet count, thus it might not work with byte count, which is much higher than packet count.
The change is under field trial and disabled by default.
Bug: webrtc:12707
Change-Id: I8b832e7920d2b4cadcd4a072b3a4d4f26a213a20
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325065
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41013}
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}
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}
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}
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}
This will be used in an experiment to ramp up BWE when BWE is reduced
due to loss.
Bug: webrtc:12707
Change-Id: I3b78f9dd3fe8ef9f94a9616640ffb8b2225e161e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324042
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40961}
This cl/ makes sure that the estimate cannot go lower than a factor of acked bitrate. The current flag LowerBoundByAckedRateFactor is set to 0, means we dont use it.
Bug: webrtc:12707
Change-Id: I75d5881f0b85a374af3f7039b82c71aee97fb7b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323881
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40958}
This ensure probe results can not be lower than 85% percentage of the
acked bitrate.
Bug: webrtc:11498
Change-Id: I501eeb84f7a049140c45c89e7de7e8080c13f94d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324040
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40957}
MinNumObservations is set to 3 per default as loss based BWE should not be ready if it has few feedbacks. We use a flag, rather than a const since we want to customize it for our unit tests, which often have 1-2 packet feedbacks only, and customize it later in prod if necessary.
Bug: webrtc:12707
Change-Id: Id1cd21aaf6137996de2e51cb5e33fc2a4bb07d8a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323780
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40952}
