The field trial has been default on for ages. This CL removes it.
Bug: b/40200151
Change-Id: I171f663a3e725b856238b14b26d083f6684586e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347621
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42080}
This CL updates RtpVideoStreamReceiver2 to use H26xPacketBuffer for
H.264 and H.265 packets. H.264 specific fixes are moved to
H26xPacketBuffer as well.
H26xPacketBuffer is behind field trial WebRTC-Video-H26xPacketBuffer.
Bug: webrtc:13485
Change-Id: I1874c5a624b94c2d75ce607cf10c939619d7b5b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346280
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42062}
This will make it harder to inadvertently register new field trials in
the wrong collection. This has happened before, see 88a8e44a51 ("Remove
nonexempt field trials from POLICY_EXEMPT_FIELD_TRIALS") for example.
Additionally, field trials will now also be validated by default before
a C++ header is generated.
Bug: None
Change-Id: I298c1345d48a522ecb95fd0f0e09834c8bdff40a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346543
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42034}
It's currently only used for testing but the initially selected end date
proved to be too short.
Bug: webrtc:13322
Change-Id: I459f315f2bad4592a1ab13190eca88a7d7cd7f90
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345703
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42031}
This is a new version of 47cfed2a7d ("Add flag to exclude policy exempt
field trials when listing expired ones") that was reverted because the
CI didn't use a hermetic version of Python. This version relies on older
Python constructs so it can be used by the CI.
Bug: None
Change-Id: I3b4794242d48c59ad94c6210c774cced362fc279
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346600
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42029}
This hard-codes the behavior to mode 3 with a threshold of 0.5 like was
already done by FetchPreEchoConfiguration.
Bug: webrtc:14205
Change-Id: I48d47a77c9df0001460788b504524203417f9647
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345483
Commit-Queue: Emil Lundmark <lndmrk@webrtc.org>
Reviewed-by: Jesus de Vicente Pena <devicentepena@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42015}
This reverts commit d427e83a15.
Reason for revert: Flaky test fixed.
Refactor FrameCandenceAdapter to keep track of input frame rate. This fixes an issue where frame rate is calculated too low if congestion window drop a frame.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887, webrtc:15893
Change-Id: I76268aa0991dbc99c1b881fb251a76aa54ff2673
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344561
Reviewed-by: Erik Språng <sprang@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41972}
This reverts commit 784af1f42e.
Reason for revert: Seems like test test_support_unittests
ResolutionAdaptsToAvailableBandwidth is flaky with this cl.
Original change's description:
> FrameCadenceAdapter keep track of Input framerate
>
> Refactor FrameCandenceAdapter to keep track of input frame rate.
>
> Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
> Uma is recorded to tell if input frame timestamp is monotonically increasing.
>
> Bug: webrtc:10481, webrtc:15887
> Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41967}
Bug: webrtc:10481, webrtc:15887
Change-Id: Id9672764768f2f40f8e711e990ad8ac18c28efcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344560
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41969}
Refactor FrameCandenceAdapter to keep track of input frame rate.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887
Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41967}
This field trial will be used to roll out support for message
interleaving (RFC8260).
Bug: webrtc:5696
Change-Id: I5f91e8910ca5949fd62362a01e66f1e9bf834f81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343765
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41955}
Adds a killswitch
WebRTC-SetCodecPreferences-ReceiveOnlyFilterInsteadOfThrow
to accompany the spec-change to throw when codec capabilities
are taken from the RtpSender instead of the RtpReceiver.
With the killswitch triggered, such codecs will be filtered.
BUG=webrtc:15396
Change-Id: I7d27111c72085eb7a7b2a1e66d0a08d12883ce17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341460
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41845}
It used up to 3 threads for QVGA on Android before. This change disables Android-specific code path in NumberOfThreads() and uses the generic settings, which configure 1 thread for resolutions <=VGA, instead. The change is guarded by a killswitch.
For reference, frame encode time for VGA 512kbps using 1 thread on Pixel 2 (7 years old device; SD835) is ~5.5ms: https://chromeperf.appspot.com/report?sid=6e80c701ef6ff0d008a299fb122a16f0d2600ddfcd9981d3d75cd722c92b2869
Bug: webrtc:15828, b/316494683
Change-Id: I0e9571ede64c6cb77d529d21ccb0310ccb8bfdaf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/337601
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41770}
Example: "WebRTC-LibvpxVp9Encoder-SvcFrameDropConfig/Enabled,layer_drop_mode:1,max_consec_drop:7/"
It is only possible to enable LAYER_DROP (layer_drop_mode=1) for now. All other modes are ignored. Max consecutive frame drops (max_consec_drop) value from the field is always applied if the field trial is enabled.
LAYER_DROP requires flexible mode (is_flexible_mode_=true) which can be enabled by means of WebRTC-Vp9InterLayerPred: https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/media/engine/webrtc_video_engine.cc;l=976
Bug: webrtc:15827, b/320629637
Change-Id: I9c4d4838b11547e608d863198b109cb1485902d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335041
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41755}
This is achieved by notifing NetEq controller of all received packets
after splitting, which then does deduping so that only useful packets
are counted.
The goal is to reduce underruns when FEC is used.
The behavior is default enabled with a field trial kill-switch.
Bug: webrtc:13322
Change-Id: I2a1a78ead1a58940ef92da0d43413eda5ba1caf3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/337440
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41665}
Low-Coverage-Reason: EXPERIMENTAL_CODE Code is behind field trial that will only be used for testing.
Bug: webrtc:13322
Change-Id: Ie306be808381b3a20b4e0d58349927bf3524018a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335840
Reviewed-by: Tomas Lundqvist <tomasl@google.com>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41608}
This field trial was added 5 years ago in
https://webrtc-review.googlesource.com/c/src/+/111883
probably as a safe guard, but looks never used.
Bug: webrtc:11503
Change-Id: Ia9544b652b25fad4c614d66fe020f3d994c96505
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/333380
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41490}
Measures the time consumed by OnFrame (e.g. the encoding time) and
sets an overload flag during N subsequent frames if the time is
longer than the current frame time. N is set to the number of
received frames on the network thread while being blocked by
encoding.
The queue overload mechanism for zero hertz can be disabled using the
WebRTC-ZeroHertzQueueOverload kill switch.
Also adds a UMA called WebRTC.Screenshare.ZeroHz.QueueOverload.
Bug: webrtc:15539
Change-Id: If81481c265d3e845485f79a2a1ac03dcbcc3ffc3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/332381
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41489}
the rollout happened in M115 without known issues.
BUG=webrtc:15096
Change-Id: I10961bfcc50450360cbf22cd60561ea3dc7e5594
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/329000
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#41269}
This uses libSRTPs srtp_remove_stream()
https://github.com/cisco/libsrtp/blob/main/include/srtp.h#L597
method to remove SSRCs from the libSRTP session when they are removed
from the RTP demuxer. This works even when the stream was added
automatically via the ssrc_any_inbound mechanism.
Only streams for inbound SSRCs that were added explicitly via SDP negotiation are removed.
Guarded by WebRTC-SrtpRemoveReceiveStream field trial.
BUG=webrtc:15604
Change-Id: I655bde5f8ddf26ac91395ef54bd1b3c598813380
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324720
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@{#41105}
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}
There's no trace of it being in use, so let's remove it.
Bug: webrtc:12497
Change-Id: I9e81ef58b459b5a0b9f79b6638231a3a19eb8a0e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322180
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Auto-Submit: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40855}
It was introduced with 98e71f57ea ("Subtract an additional 5kbps of
the bitrate when backing off.").
Bug: webrtc:13402
Change-Id: Icf8c633fa5086ac1f854a112d8eaeaf47d1ae211
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321844
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Auto-Submit: Emil Lundmark <lndmrk@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40836}
