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}
When a value is set in RtpEncodingParameters::codec, the corresponding
payload_type will be set in the SDP a=rid: line.
a=rtpmap:96 VP8/90000
...
a=rtpmap:97 VP9/90000
...
a=rid:r0 send pt=96
a=rid:r1 send pt=97
Bug: webrtc:362277533
Change-Id: Ia9688a5fc83c53cf46621d97e87f8dd363a4d7f0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361240
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43049}
Passing Environment instead of Clock into this class simplifies some plumbing for downstream consumers that need to read field trials within this class.
Bug: webrtc:362762208
Change-Id: Ia501e9f7f1d91a8115a2f71fb005dd35146db172
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362535
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43048}
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}
since clang 3.7 dates to 2015 and is obsolete.
Fuchsia has been fixed: https://issues.fuchsia.dev/issues/42051468
BUG=None
Change-Id: Id0966c3f4acfb1756eab4e2e6f0dbe52d70ecd76
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362571
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43044}
This class calculates the corruption score based on the given samples from two frames.
Bug: webrtc:358039777
Change-Id: Ib036f91ec16609e827137cc35d342a2c49764737
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362801
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43043}
For key frames: increase the sequence index until the last 7 bits are
all zeroes. If this results in an overflow, wraparound to 0.
Also:
* Allow setting and getting the sequence index
* Allow getting LayerId
Bug: webrtc:358039777
Change-Id: Ibe16689a3d1eb5706d4fce5c9220770046f26896
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362540
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Fanny Linderborg <linderborg@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43042}
We need to have imported proto as proto_data_sources in BUILD.gn to
run the action remotely without workaround config in siso.
Bug: b/366137880
Change-Id: I053774f00b761520a8a85154e386da3edb8f39b4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362680
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Auto-Submit: Takuto Ikuta <tikuta@google.com>
Commit-Queue: Takuto Ikuta <tikuta@google.com>
Cr-Commit-Position: refs/heads/main@{#43040}
which is no longer used. Also the blink::WebRTCKeyType it refers
to no longer exists either
BUG=None
Change-Id: I8236ed906b5712d11173dfcf181f556b1ff597f8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362387
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43038}
The `requested_resolution` API must not change aspect ratio, example:
- Frame is 60x30
- Requested is 30x30
- We expect 30x15 (not 30x30!) as to maintain aspect ratio.
This bug was previously fixed by making VideoAdapter unaware of the
requested resolution behind a flag: this seemed OK since the
VideoStreamEncoder ultimately decides the resolution, whether or not
the incoming frame is adapted.
But this is not desired for some non-Chrome use cases. This CL attempts
to make both Chrome and non-Chrome use cases happy by implementing the
aspect ratio preserving restriction inside VideoAdapter too.
This allows us to get rid of the "use_standard_requested_resolution"
flag and change the "VideoStreamEncoderResolutionTest" TEST_P to
TEST_F.
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I1dfd10963274c5fdfd18d0f4443b2f209d2e9a4b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362720
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43037}
Use the DTX state from inside the Opus encoder instead of trying to
mimic the logic outside.
Bug: None
Change-Id: I852044fee261a5b7f9255c557a27adfd0b1701bd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362640
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Commit-Queue: Lionel Koenig <lionelk@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43034}
This adds payload types to the codecs at the time when offer
is being generated, if they are unassigned at that point.
Bug: webrtc:360058654
Change-Id: I231ed057ebaf7fb0fffaf6ff5d600b064ba21f5b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362282
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43033}
They are now passed as part of the Environment
Bug: webrtc:362762208
Change-Id: I02868e9f41533a546f62fe30fdc6f3a7708eb346
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362084
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43032}
This will help to reduce redundant ScalabilityMode to temporal layer
count mapping in blink.
Bug: chromium:40763991
Change-Id: Ida3e6abb91383e27465eb1b697ad9431935cf9ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362486
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43031}
The recently added tests resulted in some .log file on some bots being
too long:
video_engine_tests_exe-VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_VideoStreamEncoderStandardOrLegacyRequestedResolutionTest_RequestedResolutionInWrongAspectRatioAndSourceIsAdapting_0-1.log
This CL makes the test names significantly shorter.
# Trivial and believed to fix purple bots, let's land ASAP
NOTRY=True
Bug: webrtc:367066321
Change-Id: I831911947af9d5639d1edb559470f1c9ae702d6e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362721
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43030}
prevent duplication
Wherever we don't include any extra information about the issue (e.g
file *and line number*), there's no need to return a presubmit result
with the file duplicated (it spams the console for no reason...)
bug: none
Change-Id: I11968f97f7c927b01f5cda6e56ea03e3ff47dfca
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362621
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#43029}
When it waits for only one frame, the test is flaky.
When it waits for two frames, it is not.
# Relying on triviality for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:367205682, webrtc:42220900
Change-Id: I14963b7a86961f438fd511aba8f29525e1f19750
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362583
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43025}
When requested_resolution uses a different aspect ratio than the source
the encoder will restrict the frame without changing its aspect ratio,
e.g. a 60x30 input frame that is restricted to 30x30 results in 30x15,
not 30x30.
While this logic works correctly in isolation, if the source also adapts
the frame size based on the sink_wants.requested_resolution that is
signaled back to the source, then the source will produce stretched
30x30 prior to the encoder which happily sends 30x30 not knowing any
wiser.
This is incompatible with the spec[1] and makes this WPT[2] fail. The
correct behavior is to NOT signal the requested_resolution back to the
source, the encoder already configures the correct resolution so this
isn't actually needed and the source shouldn't need to know this API.
In order not to break downstream projects, the new behavior is landed
behind a flag and both behaviors are tested with TEST_P.
This unblocks launching scaleResolutionDownTo API on Web. Migrating
from old to new code path and deleting the flag is a follow-up AI:
webrtc:366284861.
[1] https://w3c.github.io/webrtc-extensions/#dom-rtcrtpencodingparameters-scaleresolutiondownto
[2] https://chromium-review.googlesource.com/c/chromium/src/+/5853944
# Relying on previous green runs for confidence due to purple bots atm,
# see b/367211396
NOTRY=True
NOPRESUBMIT=True
Bug: webrtc:366067962, webrtc:366284861
Change-Id: I7fd1016e9cc6f0b0b9b8c23b0708e521f8e12642
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362541
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43024}
The class itself and its unit test remains, for now, but will be removed
later.
Bug: webrtc:14867
Change-Id: I36cec8fca7913663f63c53622ed2760e5e048c2f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362580
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43023}
which may show useful debug logging.
Also document that we need to forward-declare the internal srtp_ctx_
struct instead of srtp_t.
BUG=webrtc:361372443
Change-Id: I76b1a4fb385af0fc1532f0ce6d0692b804f003dd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360182
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43022}
This API should not modify the aspect ratio of the frame, e.g. if the
frame is 1280x720 and requested_resolution is 1280x360, the result
should be 640x360, not a streched out 1280x360 frame. The spec version
of this API calls this "maxWidth" and "maxHeight" which is the right
way to think about it rather than a forced width and height.
VideoAdapter continues to be used to apply adaptation restrictions, but
we now make sure to calculate the correct frame size BEFORE applying
restrictions. Prior to this CL, the VideoAdapter was also used to apply
requested_resolution restrictions. This is actually wrong and would
cause strange scaling factors in some cases, e.g. f=1280x720 + r=720x405
would result in 640x360 instead of 720x405. Now we make f=720x405 first
and only adjust further if restrictions or alignments require us to.
Since this is a change in behavior a WebRtcVideoChannelTest is updated.
Encodings integration test is also added, both for aspect ratio (new
behavior) and orientation agnosticism (old behavior still passing).
Bug: webrtc:366067962
Change-Id: I4e8dc27da5a84d73238b8ab74ef197eb5ee8072a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43020}
