This reverts commit bdc669347c70160cd648f5cab7a417227d41d82a.
Reason for revert: AUDs will be taken into account now.
video_replay with the provided out.pcap and these options:
--codec H264 --input_file out.pcap --media_payload_type 102 --ssrc 40000
plays smoothly.
Original change's description:
> Revert "h264: fix first_packet_in_frame logic for multislice in a single rtp packet"
>
> 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}
Bug: webrtc:368335257
Change-Id: Idfae2efc1ebd7b97a2f7ebbd9d1e8c7bf6fcc348
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363842
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43113}
since 1024 is already deprecated by OpenSSL and causes "too small key"
issues on systems enforcing a minimum size. Similar issue here:
https://github.com/nodejs/node/pull/44498
The minimum key size is not yet changed from 1024, this will require more effort for deprecation.
BUG=webrtc:364338811
Change-Id: Id4b24a2c289ec5e3f112288d32b8ac697ba1cfed
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361128
Reviewed-by: David Benjamin <davidben@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#43110}
As of [1], a single VP9 encoder instance can produce simulcast 4:2:1.
When it does, the EncodedImage has its simulcast index set (0, 1, 2).
The bug is that if you then go back to a single encoder instance,
either because you're doing singlecast or because you're doing
simulcast with scaling factors that are not power of two (not 4:2:1),
then the simulcast index which was previously set to 2 is not reset due
to the old code path never calling SetSimulcastIndex.
Example repro:
1. Send VP9 simulcast {180p, 360p, 720p}, i.e. 4:2.1.
2. Reconfigure to {180p, 360p, 540p}, i.e. no longer 4:2:1.
What should happen: all three layers are sent.
What actually happened: 180p is not sent and the 540p layer flips flops
between 180p and 540p because the EncodedImage says simulcast index is
2 for both encodings[0] and encodings[2].
The fix is a one-line change: `SetSimulcastIndex(std::nullopt)` in the
case that we don't have a `simulcast_to_svc_converter_` that sets it
(0, 1, 2) for us.
[1] https://webrtc-review.googlesource.com/c/src/+/360280
Bug: chromium:370299916
Change-Id: I52bd4428bd12528f0e98869ec61626c06f589b43
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363941
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43109}
The code now uses NetEq directly instead of AcmReceiver.
Bug: webrtc:14867
Change-Id: I11c7e2ca00060ab15bba5ec67dfd92ec413196f6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364140
Commit-Queue: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43108}
Based on https://webrtc-review.googlesource.com/c/src/+/362740 we can now simplify the MergeRtpHdrExts since there is no longer need to keep track of the `regular_extensions` and `encrypted_extensions` separately.
Bug: chromium:40623740
Change-Id: Iff94931e87a7b9301ac58d4c5c2c975b9f9fe57a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363880
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Cr-Commit-Position: refs/heads/main@{#43107}
By this change we aim to remove the flag enable-webrtc-srtp-encrypted-headers.
Bug: chromium:40623740
Change-Id: I74692c90ff1caf2a11d7b73211c1ae4472edfb4d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362740
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Emil Vardar (xWF) <vardar@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43105}
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}
