and ensure there is only one, similar to what is done with RTX.
This avoids exposing a payload type there.
See also
https://github.com/w3c/webrtc-pc/issues/2696
BUG=webrtc:42221750,webrtc:360058654
Change-Id: Id7c2ddeaf47a3169db9be43c9c5b8e59346f1d57
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376760
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43929}
Follow-up to
https://webrtc-review.googlesource.com/c/src/+/375847
moving to a big outer loop over formats instead of calling the inner loop with single-element arrays.
BUG=webrtc:360058654
Change-Id: I7d263c1014d80f2312bf93595ee8e8ef9c4e7953
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376081
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43896}
This is a reland of commit 1ad3e14e9981772554a848c5034c7c555680aef7
The original CL removes all sending streams since all codec types has
been attempted for encoding and we have no other codecs to fallback to.
However some downstream applications will still attempt to set the codec
preferences even all send streams have been removed.
As a result, we follow previous logic to keep the send streams, to avoid
the regression.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918, b/384725754
Change-Id: Ifd48b30b80ae51c3ede9391ed62e8ce408864aa0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374852
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43874}
This CL fixes two issues with the old way targetBitrate was reported:
1. The target is per encoder, i.e. per SSRC, but the old way to report
it was per sender and was approximately the sum of all encodings'
targetBitrate in most cases.
2. The old value did not come directly from the VideoBitrateAllocation
and tended to be greater than the sum of all targets (don't know
why).
We know the old value was wrong and the new value correct because
the actual bytes produced by the encoder closely matches the configured
target, which wasn't always the case with the old metric implementation.
Tested with unit tests and manually in Chrome by going to
https://henbos.github.io/codec-quality/src/index.html and ensuring
target ~= actual bytes produced. It also matches the debug logging of
video_stream_encoder.cc.
Bug: webrtc:42225524, chromium:392424845
Change-Id: I7a6f69e053ebc3fd972c2c4b7712750e721c0acc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/376460
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43854}
and make it less opus-specific.
BUG=None
Change-Id: I6fe2975ba6e45a3758fedc5b950de90e8d9df362
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375436
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43846}
Adds test coverage for the following mitigations (need both to pass):
1. https://webrtc-review.googlesource.com/c/src/+/375847
2. https://webrtc-review.googlesource.com/c/src/+/376022
Like the comment says, this is neither mandated by the spec or
guaranteed, but when the number of codecs is quite small like it is in
this test it will be true for all RTX codecs.
Bug: webrtc:360058654
Change-Id: Ib73cea59d06a62390dd039eb2dc04677d6178460
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375865
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43841}
Changes the order of payload type assignment to keep the rtx_pt =
primary_pt+1 pattern (even if not required by the specification)
On https://webrtc.github.io/samples/src/content/peerconnection/pc1/ this
changes PTs as follows:
M132: m=video 9 UDP/TLS/RTP/SAVPF 96 97 102 103
104 105 106 107 108 109 127 125 39 40 45 46 98 99 100 101 112 113 114
(121 more lines) mid=1
M134: m=video 9 UDP/TLS/RTP/SAVPF 96 109 99 118 100 119 101 120 103 121
104 122 37 123 40 127 97 114 98 115 107 44 108 (121 more lines) mid=1
M134 with this patch: m=video 9 UDP/TLS/RTP/SAVPF 96 97 107 108 109 114
115 116 117 118 119 120 37 121 40 124 98 99 100 101 127 42 43 (121 more
lines) mid=1
Note that this pushes red and ulpfec into lower range but those codecs
are not widely used and it is possible to get them back into the upper
range e.g. by using setCodecPreferences to disable H264 (where ulpfec is
not supported)
BUG=chromium:391132280
Change-Id: I892f00a2f276728d16c37e8ba5f76d01f6322a7d
No-Iwyu: single include missing, keep it more merge-able
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/375847
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Commit-Queue: Guido Urdaneta <guidou@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43833}
This is a reland of commit bcb19c00ba8ab1788ba3c08f28ee1b23e0cc77b9
Original change's description:
> Allow sending to separate payload types for each simulcast index.
>
> This change is for mixed-codec simulcast.
>
> By obtaining the payload type via RtpConfig::GetStreamConfig(),
> the correct payload type can be retrieved regardless of whether
> RtpConfig::stream_configs is initialized or not.
>
> Bug: webrtc:362277533
> Change-Id: I6b2a1ae66356b20a832565ce6729c3ce9e73a161
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364760
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Florent Castelli <orphis@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43197}
Bug: webrtc:362277533
Change-Id: Ia82c3390cceb9f68315c2fd9ba5114693669af32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374780
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43787}
In order to reduce the size and scope of a follow-up CL, this CL makes
some cleaning up and improvements to existing tests and adds some minor
test utility methods that will be used in the follow-up.
No change in behavior, this CL...
- Makes use of NiceMock in RtpTransceiver tests to avoid wall of text
spam for various "uninteresting" method calls in all tests in this
file.
- Refactors creating senders, receivers and transceivers to allow the
follow-up CL to create such objects for kind "video" as well.
- Exposes cricket::FakeVideoEngine* to RtpTranscieverTest and allows
adding unidirectional video codecs in the fake engine, to be used by
the follow-up CL's tests.
- Allows creating fake video engine codecs from SdpVideoFormat in the
fake decoder factory (already possible in the fake encoder factory).
Bug: chromium:381407888
Change-Id: Ie07eff79d832dd21800b95fd584891ebf4520798
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374900
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43776}
In order to align with this PR[1], setParameters() should not throw if
the H265 level ID we're trying to send does not match what was
negotiated. This was believed to be fixed by [2] but we were still
throwing due to a check on a different layer (media_engine.cc).
In order to reproduce the issue despite WebRTC lacking SW
encoder/decoder for H265, peer_connection_encodings_integrationtest.cc
gets a new test with real stack but fake encoder/decoder factory. This
allows negotiating H265 and doing SetParameters() even though the codec
is not processing any frames.
- Basic test coverage is added for singlecast and simulcast H265.
- Test coverage for the bug being fixed added.
- In Chrome the equivalent WPTs exists for when real HW is available
here[3]. Those tests PASS with this CL (currently FAIL).
[1] https://github.com/w3c/webrtc-pc/pull/3023
[2] https://webrtc-review.googlesource.com/c/src/+/368781
[3] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/webrtc/protocol/h265-level-id.https.html
Bug: chromium:381407888
Change-Id: I3619a124586b8b26d3695cfad8890cf40bd475db
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/374164
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43759}
When incoming codec_settings_list size is more than
the internal RTP source indentifiers, then it would
cause an invalid memory acccess.
The fix is to operate the stream config update only
when these sizes are match.
Bug: chromium:378724147
Change-Id: I2195df82e0e05619cd2a9bc2d4cb5e8f3efa1446
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368120
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43603}
This reverts commit 1ad3e14e9981772554a848c5034c7c555680aef7.
Reason for revert: Breaks downstream project. We are investigating into a potential problem when running on mobile platforms. We will get back with info or reland.
Original change's description:
> Follow codec preference order for sending codec fallback.
>
> When encoder selector is not enabled, currently we always fallback to
> VP8 no matter how the codec preference is setup. Update to follow codec
> preference order for the fallback.
>
> Bug: chromium:378566918
> Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43566}
Bug: chromium:378566918
Change-Id: I09086b5ad100a8f66e87df167e903d0b5fe5b589
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/372080
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43600}
When encoder selector is not enabled, currently we always fallback to
VP8 no matter how the codec preference is setup. Update to follow codec
preference order for the fallback.
Bug: chromium:378566918
Change-Id: Ia3fbfc9d407683ef7b3d6246af7e9ec58535dc89
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370707
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43566}
This reverts commit e046787a5a80a9d292b3aec7e946644e025a2b95.
Reason for revert: Revised codec matching to fix issue.
Changes also back out some changes that should not have been
included (using PayloadTypePicker for codec list merging).
Original change's description:
> Revert "Use PayloadTypePicker for video PT assignment"
>
> This reverts commit e5048949b0fcc275264e24f3b2a4c658fcc84aa3.
>
> Reason for revert: Broke internal tests.
>
> Original change's description:
> > Use PayloadTypePicker for video PT assignment
> >
> > This includes changes that change the order of codecs.
> > It is preparatory to doing late assignment of video PTs.
> >
> > Bug: webrtc:360058654
> > Change-Id: Id5ddaf94d4b9557c0502a373e42635108d8fdf26
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366400
> > Reviewed-by: Henrik Boström <hbos@webrtc.org>
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/main@{#43489}
>
> Bug: webrtc:360058654
> Change-Id: I5c94a7bafa49bdf17f665480398707155e458d26
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370240
> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43490}
Bug: webrtc:360058654
Change-Id: I66b3b6bd657c66f8860c5e67a504266d7707f48d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370380
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43554}
The video engine MapCodecs function returned an empty list of
codecs when errors occured, which caused crashes downstream.
This created issues with diagnosing errors caused by PT redesign.
Bug: webrtc:360058654
Change-Id: I0b5bdc9f95814ac4cfb99f749075990c3077e7a6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370420
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43499}
This reverts commit e5048949b0fcc275264e24f3b2a4c658fcc84aa3.
Reason for revert: Broke internal tests.
Original change's description:
> Use PayloadTypePicker for video PT assignment
>
> This includes changes that change the order of codecs.
> It is preparatory to doing late assignment of video PTs.
>
> Bug: webrtc:360058654
> Change-Id: Id5ddaf94d4b9557c0502a373e42635108d8fdf26
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366400
> Reviewed-by: Henrik Boström <hbos@webrtc.org>
> Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43489}
Bug: webrtc:360058654
Change-Id: I5c94a7bafa49bdf17f665480398707155e458d26
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370240
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43490}
This includes changes that change the order of codecs.
It is preparatory to doing late assignment of video PTs.
Bug: webrtc:360058654
Change-Id: Id5ddaf94d4b9557c0502a373e42635108d8fdf26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366400
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43489}
For-loop has a 'continue' statement that skips increment of the index.
Added such an increment before 'continue' for the index to keep up with
the for-loop.
I guess current implementation will bug on codecs sequence like:
'red, unknown, opus'
since the subsequent for-loop (the 'red_codec' one) will not be able to
find 'opus'.
Seems like adding second increment statement is the easiest way to fix it.
Bug: None
Change-Id: Iab9cc66cf569458af9fd9ba5b938d83186c78c73
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369700
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43488}
also fix a few TODOs
Bug: None
Change-Id: I2d287ed1a58f71ef32d5dc5624879ae8c63348b5
No-Try: True
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/370122
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43485}
The RTCP mode is a send property for both send and receive channels. Send properties should be configured based on what peers support/prefer, which is described by the remote description (content).
Bug: webrtc:340041654
Change-Id: I18cd59e98aecfbbd8f4919b98381836184c10d77
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368980
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tomas Lundqvist <tomasl@google.com>
Cr-Commit-Position: refs/heads/main@{#43449}
According to latest requirement, when the level reported by
RtpSender.getCapabilities() for H.265 is different from that was
negotiated, we should not throw when setParameters() is called with
level-id set to that reported by RtpSender.getCapabilities().
Underlingly negotiated codec level should remain unchanged.
Bug: chromium:41480904
Change-Id: I28bbdb5f0a0ab0d98315f56c80004601afc91a63
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368781
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43434}
This is preparatory to ensuring that transport-cc gets turned off when
RFC8888 ccfb is negotiated.
Bug: webrtc:378698658
Change-Id: Ie76677bd6aa046701562bbd93d8489858488f863
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368543
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43426}
This is a reland of commit 775639e930f14a619974944594b40c633cc574a3
Original change's description:
> Set default scalability mode for H.265 to L1T1.
>
> H.265 does not have software fallback, and it may have issue supporting
> more than 1 temporal layers on some devices. Set default to L1T1 when
> scalability is not configured, or if a scalability mode is reported as
> not supported by encoder.
>
> Bug: chromium:41480904
> Change-Id: I53895c45ec821d65774ffe2db5f418184e3fb02a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367835
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Cr-Commit-Position: refs/heads/main@{#43389}
Bug: chromium:41480904
Change-Id: Idedf6249130bd01dd31261672c624b88c3f4c1de
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368261
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43412}
This seems to have no effect on tests, so it appears that these were
not used after all.
The goal is to make transport-cc a media-section-level attribute.
Bug: webrtc:378698658
Change-Id: Ia20ca5b91472b02db30f911ad1a1892cf36cd682
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368440
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43411}
This will turn on RFC 8888 feedback messages if "ack ccfb" is negotiated.
This should eliminate the need for the "force" flag in the field trial.
Bug: webrtc:42225697
Change-Id: Iec7a894c244a417a8499200861550a33f89966a2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367400
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43398}
This reverts commit 775639e930f14a619974944594b40c633cc574a3.
Reason for revert: Breaks internal tests.
Original change's description:
> Set default scalability mode for H.265 to L1T1.
>
> H.265 does not have software fallback, and it may have issue supporting
> more than 1 temporal layers on some devices. Set default to L1T1 when
> scalability is not configured, or if a scalability mode is reported as
> not supported by encoder.
>
> Bug: chromium:41480904
> Change-Id: I53895c45ec821d65774ffe2db5f418184e3fb02a
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367835
> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
> Cr-Commit-Position: refs/heads/main@{#43389}
Bug: chromium:41480904
No-Try: true
Change-Id: I5485b1abfd5f586ec187cc57817940aa2efd72af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368200
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Jeremy Leconte <jleconte@webrtc.org>
Owners-Override: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43396}
H.265 does not have software fallback, and it may have issue supporting
more than 1 temporal layers on some devices. Set default to L1T1 when
scalability is not configured, or if a scalability mode is reported as
not supported by encoder.
Bug: chromium:41480904
Change-Id: I53895c45ec821d65774ffe2db5f418184e3fb02a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367835
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jianlin Qiu <jianlin.qiu@intel.com>
Cr-Commit-Position: refs/heads/main@{#43389}
The std::lcm and std::gcd functions are part of the C++ standard
library. The existing functions are marked as deprecated rather than
deleted in the case of possible third party uses.
#rtc_cleanup
Bug: webrtc:377205743
Change-Id: I174e663f152d750c984a35dc7136bc18dc01bc8e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367440
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Auto-Submit: Evan Shrubsole <eshr@google.com>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43368}
Inactive encoders are included in the string when they are paused due to
bitrate allocation being 0 for that simulcast layer.
#rtc_ktlo
Bug: webrtc:376804631
Change-Id: I4234b452b60fee58981907380df41962fda5bf40
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/367660
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43367}
Increased the number of errors the automation is fixing to 150 from
75 in this commit.
Bug: webrtc:370878648
Change-Id: If6e6a5f40db7eb54c27c1a85fb7031838e478c70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366205
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Dor Hen <dorhen@meta.com>
Cr-Commit-Position: refs/heads/main@{#43337}
This is a reland of commit 82617ac51e7825db53451818f4d1ad52b69761fd
The reason for the revert was a downstream use of
`rtc::VideoSinkWants::requested_resolution`, so in this reland we don't
rename this field, it's fine just to rename the one in
RtpEncodingParameters for now.
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
NOTRY=True
Bug: webrtc:375048799
Change-Id: Ic4ee156c1d50aa36070a8d84059870791dcbbe5e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366660
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43304}
This reverts commit 82617ac51e7825db53451818f4d1ad52b69761fd.
Reason for revert: Break downstream projects
Original change's description:
> Rename `requested_resolution` to `scale_resolution_down_to`.
>
> This is a pure refactor/rename CL without any changes in behavior.
>
> This field is called scaleResolutionDownTo in the spec and JavaScript.
> Let's make C++ match to avoid confusion.
>
> In order not to break downstream during the transition a variable with
> the old name being a pure reference to the renamed attribute is added.
> This means we have to add custom constructors, but we can change this
> back to "= default" when the transition is completed, which should only
> be a couple of CLs away.
>
> Bug: webrtc:375048799
> Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
> Commit-Queue: Henrik Boström <hbos@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#43300}
Bug: webrtc:375048799
Change-Id: Ie41723a39420e12e7b5b681d3d00ccd14f66b4b1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366642
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#43301}
This is a pure refactor/rename CL without any changes in behavior.
This field is called scaleResolutionDownTo in the spec and JavaScript.
Let's make C++ match to avoid confusion.
In order not to break downstream during the transition a variable with
the old name being a pure reference to the renamed attribute is added.
This means we have to add custom constructors, but we can change this
back to "= default" when the transition is completed, which should only
be a couple of CLs away.
Bug: webrtc:375048799
Change-Id: If755102ccd79d46020ce5b33acd3dfcc29799e47
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366560
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43300}
This is similar to MatchesRtpCodec but not an exact match of parameters, unspecified parameters are treated as default. Use IsSameRtpCodec for comparison when codec is configured via encodings.
Bug: b:299588022
Change-Id: I0ea800e50af6f5666e3e867a928e15b0aa044635
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365142
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43272}
We should use the Timestamp type, rather then int64, to store timestamps. In https://webrtc-review.googlesource.com/c/src/+/365001/ an additional int64 timestamp was added (last_sender_report_timestamp_ms).
This CL fixes the new timestamp, as well as other similar timestamps in MediaReceiverInfo (last_sender_report_utc_timestamp_ms and last_sender_report_remote_utc_timestamp_ms).
Bug: webrtc:372393493
Change-Id: I0e473730e85a69ec595b421e2c3db920364008eb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365641
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43248}
std::optional<T>::emplace() without a value is broken
on clang++ with gnu libstdc++. this workarounds the bug
by using the assignment operator instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227
Bug: None
Change-Id: I6fd096ff4d632259e6eab776e318c1d7b15e4bd5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365400
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43229}
Add an environment clock timestamp to SenderReportStats and make it visible in rtc_stats_collector.cc. This make it possible to use the pc->GetConfiguration().stats_timestamp_with_environment_clock() flag to decide which timestamp to use when creating a RTCRemoteOutboundRtpStreamStats object.
This CL is the third (and possible the last) of a series of CLs that aim to replace the UTC timestamps in RTCStats objects to Environment clock timestamps. The other CLs where https://webrtc-review.googlesource.com/c/src/+/363946 and https://webrtc-review.googlesource.com/c/src/+/364782.
When Chromium and Google internal uses of RTCStats are updated to set the stats_timestamp_with_environment_clock configuration, the flag can be deleted.
Bug: chromium:369369568
Change-Id: Ic0b07d7b012505267bd6516f19a9ba90df4cafab
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365001
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43206}
I missed one timestamp in https://webrtc-review.googlesource.com/c/src/+/363946, meaning that the config flag that was added do not yet work for all timestamps in RTCStats objects. The RTCRemoteOutboundRtpStreamStats still has UTC timestamps even if the config flag is set.
I will solve this by saving both an UTC (existing) and env (to be added) timestamp, and then let rtc_stats_collector choose timestamp based on the value of the config flag (just like RTCRemoteInboundRtpStreamStats is done in the 363946 commit).
Before adding the new env_ timestamp I want to make this change. I rename the existing timestamp to show what epoch it uses (NTP or UTC). This will later make it clear which timestamp is which.
So this CL will make no logical change, just renaming members.
I only need to rename the last_sender_report_timestamp_ms, but opted to rename the remote timestamp as well, to be consistent with the naming convention I add in this CL.
Bug: chromium:369369568
Change-Id: Icfe7cf274995b39799e1478a1bb8cdf5134f0b16
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364782
Commit-Queue: Olov Brändström <brandstrom@google.com>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43194}
I have implemented that adds multiple codec settings to RtpConfig and
passes them down to the lower layers from WebRtcVideoSendChannel.
Bug: webrtc:362277533
Change-Id: I088d6583f7dcbd4de5deb1e9e08c80a6dc10494f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/364440
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43166}
