The same as https://webrtc-review.googlesource.com/c/src/+/331340, but
for interleaved messages.
This avoids inserting into maps where possible, and also fixes a bug
when the payload was accidentally copied unintentionally -
crbug.com/365594101.
Bug: chromium:365594101
Change-Id: Iaeaa97b0cf3a26ada9afc61f2545760b7ab4c731
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363960
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43099}
Move it away from the "proprietary" SSL_CIPHER_get_id and looking up the cipher based on that towards SSL_CIPHER_standard_name.
SSL_CIPHER_get_id and the associated GetSslCipherSuite API is kept around for
WebRTC.PeerConnection.SslCipherSuite.*
UMA metrics and metrics compability (despite not yielding the IANA ids it promises).
BUG=None
Change-Id: Iaa357e3e31dc90abea688cf6ca10c0b40582ef38
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363202
Reviewed-by: David Benjamin <davidben@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43097}
RTCVideoEncoder in chromium use it to generate dependency template
and generic frame info for hw encode accelerators after encoding.
https://chromium-review.googlesource.com/c/chromium/src/+/5849272
Bug: chromium:40763991
Change-Id: I96396ad972bf18790b09508e428c6362aae24a65
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362151
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Yingying Ma <yingying.ma@intel.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43087}
The tests exercise the new encoder API that is not used in prod yet.
Bug: webrtc:369633254
Change-Id: Iee6bc16ebd471f4accdd9531cdb404f159557f51
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363820
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43083}
Those trigger new warnings when importing the Chromium roll
Bug: None
Change-Id: Ica71cc83f5bbfd8fec4736185d389b9e82f2276e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363740
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43080}
If the upper limit is infinite, dont probe.
Bug: webrtc:42224658
Change-Id: Ia662cceded83969ec11ee013adb2100f983fbd13
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363660
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43079}
Add field trial parameter for setting scale factor of max allocated bitrate used for deciding when to skip probing.
Currently, a factor of 2 is used in most places for max allocated bitrate but not if the field trial skip_estimate_larger_than_fraction_of_max is used.
The purpose of this new field parameter is to be able to harmonize and always use the same factor.
Bug: webrtc:42224658
Change-Id: I5e1580b9bb18ef881b819affc0b4038094e94316
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363400
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43078}
This aligns to probe limits in ALR for example.
Bug: webrtc:369044000, b/369021234
Change-Id: I3823b308cf97a8b7060b35b2ac38864e75d6f983
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363301
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43074}
The reason we are doing this is because the "committers" group grants access to Code-Review, and we now have a policy that such groups must only contain direct human users. However, we still want robot accounts to be able to CQ+2, so we now have the -submit-access group that includes anyone who can CQ+2, not just committers.
Bug: chromium:356276684
Change-Id: I39c3b92110ff10f53a2825f5e12690580331364d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363480
Reviewed-by: Christoffer Dewerin <jansson@webrtc.org>
Auto-Submit: Joey Scarr <jsca@google.com>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43073}
Setting the standard deviation to 0 is valid and should be interpreted
as directly using the sample value at the coordinates without weighting.
This is made explicit in the documentation for the Corruption Detection
extension:
http://www.webrtc.org/experiments/rtp-hdrext/corruption-detection
Also, change stddev to std_dev in halton_frame_sampler files.
Bug: webrtc:358039777
Change-Id: Id5aa4110194f7f2b2fe9914c94304c90afd64198
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363300
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43070}
Level asymmetry is implicitly enabled for HEVC. When comparing two
codec params to see if they match, we only compare profile & tier,
similar as H.264.
Bug: chromium:41480904
Change-Id: I9e9debdf1b34f33986da9344b9fee14071b1ed60
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363205
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43069}
Ensure probing is not instantiated again until after timeout if a probe has been sent to max rate.
Bug: webrtc:42224658
Change-Id: I7d0d2edcfa81b1b454ea5748962af5a2070b347c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363240
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43068}
We currently specify stream parameters to be a range for both framerate
and resolution, where preferred value is specified. The preferred value
doesn't seem to be taken into account and we end up accepting resolution
from 1x1 to MAX_INTxMAX_INT. In case the other side tries to first match
with lower resolution than requested, we will happily match it and start
streaming low quality video. We should instead request the exact stream
parameters as specified by requested capability. This capability always
come from what has been originally reported as supported so it shouldn't
happen we don't find a matching stream. This also applies to requested
video format. We previously requested mjpg for streams with resolution
higher than 640x480, but it doesn't necessarily mean the camera supports
mjpg for the requested resolution. Again, refer to requested capability
in this case as it should indicate what is supported and we know we can
request exactly the same video format. It can happen that framerate is
set to 0 as unspecified. In that case keep using a range as before, but
with more sane values.
Bug: webrtc:42225999
Change-Id: I46d8e83c636e25e12c45a462596fee1d5e59888e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362820
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Andreas Pehrson <apehrson@mozilla.com>
Cr-Commit-Position: refs/heads/main@{#43067}
This is a reland of commit e77d75193f4f61cf90991569c5470ba5d1b78f2b.
No changes were required to the CL, downstream tests have been fixed.
Original change's description:
> Disable TLS session ticket for DTLS
>
> since it makes no sense for the WebRTC usage of DTLS and increases
> the size of the last handshake flight considerably
> Guarded by killswitch
> WebRTC-DisableTlsSessionTicketKillswitch
>
> BUG=webrtc:367181089
>
> Co-authored-by: Jody Ho <jodyho@meta.com>
> Change-Id: I4bb17bba8a17c65c8e0fefe2d8962974703feee7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362526
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: David Benjamin <davidben@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@meta.com>
> Cr-Commit-Position: refs/heads/main@{#43046}
Bug: webrtc:367181089
Change-Id: I4b3f813e4a0dd4d0458ee14c15c51ee6f9b84461
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363220
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43066}
This reverts commit 3753c8190e3f0aca6758a5521e33f8b5d4f09ab4.
Reason for revert: Break assembling of hardware encoded h264 P frame on
weak network condition.
Original change's description:
> h264: fix first_packet_in_frame logic for multislice in a single rtp packet
>
> a frame must be (or should be) first when it contains either SPS (but not just PPS),
> is an IDR or is a slice with first_mb_in_slice == 0.
>
> Fixes an edge case where a STAP-A with SPS, PPS and multiple slices of an IDR fit
> into a single RTP packet which can happen with small 320x196 frames
>
> BUG=webrtc:352379280,webrtc:346608838
>
> Change-Id: Ic6dea6c81db759d0d7ddd4054407103fd791f6c5
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357121
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#42652}
Bug: webrtc:368335257
Change-Id: I07725c78be628bff71b79b8b9369677e39f5f5ac
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363080
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43062}
The code that restricts the maximum number of simulcast layers based on
resolution is a spec-compliance bug and doesn't make much sense: if the
app asks for 3 layers it should get 3 layers. Since the app knows the
size of the track, it could very easily ask for 1 layer when resolution
is small if that is the behavior it wanted. If the app doesn't ask to
disable layers, WebRTC shouldn't disable layers on its behalf.
This behavior makes even less sense with this "new" API since the app
is explicitly controlling the send resolution in absolute terms.
Removing this behavior in the general case is out of scope since it
would break backwards compatibility, but since `requested_resolution`
has not been exposed to the web yet and existing usage is small, this
is an opportunity to fix the compliance bug for this API.
This CL makes the last web platform test for "scaleResolutionDownTo"
pass.
Bug: chromium:363544347
Change-Id: Ic6fadf3cad69d3beec4ae03d3d031e8062382ad9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43061}
The FrameInstrumentationGenerator is responsible for generating the
instrumentation data that will be used to detect corruption. The data is
then passed to the encoder in the CodecSpecificInfo.
Bug: webrtc:358039777
Change-Id: I79d0534920b4c7fa001e1138371dfd36c13424fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362584
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Fanny Linderborg <linderborg@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43060}
In many cases, the framerate can be specified as list of possible values
and in that case, we would end up with max FPS to be set to 0 as this
case was not handled.
Bug: webrtc:42225999
Change-Id: I036af6db1da3309b1310b754504369e8fe392d09
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362961
Commit-Queue: Jan Grulich <grulja@gmail.com>
Reviewed-by: Andreas Pehrson <apehrson@mozilla.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43057}
This is a follow up for https://webrtc-review.googlesource.com/c/src/+/360680.
* Adding some missing <optional> include.
* Adding a IWYU pragma to force keeping an include.
Note that I've added the CQ bot 'iwyu_verifier' to ensure the repo stays clean. It is still work in progress and it currently needs to be triggered manually.
FYI I used these command line to run iwyu:
> for i in api/*.cc; do ./tools_webrtc/iwyu/apply-include-cleaner $i; done
> for i in api/*.h; do ./tools_webrtc/iwyu/apply-include-cleaner $i; done
Change-Id: Ie7036d08edbb6884f2b35eb9d69646757d662390
Bug: webrtc:42226242
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362440
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jeremy Leconte <jleconte@google.com>
Cr-Commit-Position: refs/heads/main@{#43054}
after cleaning up the Chromium dependency
BUG=webrtc:42225170
Change-Id: Icd3934ca51f829c55e061fc1943500435c845a8d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362569
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43053}
This reverts commit e77d75193f4f61cf90991569c5470ba5d1b78f2b.
Reason for revert: Speculative rollback (breaks downstream test).
Original change's description:
> Disable TLS session ticket for DTLS
>
> since it makes no sense for the WebRTC usage of DTLS and increases
> the size of the last handshake flight considerably
> Guarded by killswitch
> WebRTC-DisableTlsSessionTicketKillswitch
>
> BUG=webrtc:367181089
>
> Co-authored-by: Jody Ho <jodyho@meta.com>
> Change-Id: I4bb17bba8a17c65c8e0fefe2d8962974703feee7
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362526
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: David Benjamin <davidben@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@meta.com>
> Cr-Commit-Position: refs/heads/main@{#43046}
Bug: webrtc:367181089
Change-Id: I02b59232fae9f729341811042a02f7cf346d4bbe
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362982
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43052}
