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 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}
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 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}
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}
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 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 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}
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}
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}
Will be later used to conditionally enable mixed codec simulcast
with a field trial.
Bug: webrtc:42220378
Change-Id: I527a488c04cd2b5a9f4ec703504b67943e966ab0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361403
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42929}
According to spec, if you ask for three encodings you get three
encodings (duh). But according to legacy code, if you ask for three
encodings AND codec is VP9, then surely you meant a single encoding that
is kSVC where the other encodings influence the scalability mode of the
first encoding.
Standard simulcast support in VP9 was shipped as an opt-in feature where
you have to specify `scalability_mode` and `scale_resolution_down_by` in
order to let WebRTC know that you want to disable the legacy path.
But `scale_resolution_down_by` is not the only way to configure
resolution, there is also the `requested_resolution` code path. This CL
adds standard simulcast support for this code path as well.
Prior to this change, our parameterized test would have passed in VP8
but failed in VP9. With this change the test passes for all codecs.
Bug: webrtc:361124448
Change-Id: Ic5a7136de8abf430813fd01342862775fca145fb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42822}
* Simplified ctor. Get settings (max_qp, content_type, etc) from encoder_config passed to CreateEncoderStreams().
* Some tests assigned VideoEncoderConfig::video_stream_factory to EncoderStreamFactory they created. That's not really needed. VideoStreamEncoder creates the factory if video_stream_factory is not provided [1]. Removed video_stream_factory initialization in tests.
[1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/video/video_stream_encoder.cc;l=1002;drc=1d7d0e6e2c5002815853be251ce43fe88779ac85
Bug: b/347150850, webrtc:42233936
Change-Id: Ie0322abb6c48e1a9bd10e9ed3879e3ed484fea5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355321
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42608}
This is in preparation for moving the assignment of PT numbers
to a different place.
Bug: webrtc:42226302
Change-Id: I821f2b6b15eb9f9f3715714e2c2c220c5e5a219e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/352921
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42422}
This is done in case the new source has a different clock source which
might be out of sync with the previous one, leading to timestamp
conflicts.
Bug: b/340198307
Change-Id: Id1a82823ca85e03d99dad31b7ce9f19f09447755
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350560
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42312}
These are aliases for cricket::Codec.
Also remove internal usage
Bug: b/42225532
Change-Id: I220b95260dc942368cb6280432a058159eec8700
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349321
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42194}
following the audio changes. Note that RTT-related fields require
DLRR and are not implemented yet.
BUG=webrtc:12529
Change-Id: I3f9449fbe876a1b282a32f2bcebe1cf3e10989bf
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346580
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Cr-Commit-Position: refs/heads/main@{#42069}
When an error occurs, the callback needs to be invoked or the
signaling thread may block indefinitely waiting for it.
Bug: webrtc:15871
Change-Id: Ib73382aff07b3632794300985223c70c24f554f4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342901
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41904}
The feature isn't in use by Google and has proven to contain security
issues. It's time to remove it.
Bug: b/324864439
Change-Id: I80344eb2f2060469d2d69a54dc4519fdd02ab4ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340324
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41808}
The feauture was added in https://webrtc-review.googlesource.com/c/src/+/291119 in order to ensure RTX packet is part of BWE even before the RTP stream is known.
However, it cause an issue if media is signaled with an SSRC that has this RTX SSRC.
Since BWE is now notified about received packets before demuxing to the correct receive stream, it is not necessary to demux RTX packets before the media SSRC is known.
Note that WebRTC require at least one negotiated SSRC/MID before RTCP feedback can be sent. Ie, for BWE to work, at least one media SSRC must be known after this cl. It can either be unsignaled or signaled.
BWE tested with BweRampupWithInitialProbeTest.
Bug: webrtc:14795, webrtc:14817, b/320258158
Change-Id: Icf2c67bedc352720bf846b9ee38d509346af36f2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340141
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41785}
by creating an id collision and letting UsedIds resolve it.
Also avoid id=15 which is forbidden by
https://www.rfc-editor.org/rfc/rfc8285#section-4.2
so might cause interop issues in offers to implementations
not supporting two-byte extensions.
BUG=webrtc:15378
Change-Id: I27926f065f8e396257294da7acf2be9802169805
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319280
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@{#41696}
Instead, always use VideoSendStream::Start.
VideoSendStream::StartPerRtpStream was used for controlling if
individual rtp stream for a RtpEncodingParameter should be able to send RTP packets. It was not used for controlling the actual encoder layers.
With this change RtpEncodingParameter.active still controls actual encoder layers but it does not control if RTP packets can be sent or not.
The cleanup is done to simplify code and in the future allow sending
probe packet on a RtpTransceiver that allows sending, regardless of the
RtpEncodingParameter.active flag.
Bug: webrtc:14928
Change-Id: I896c055ed4de76db58d76f452147c29783f77ae1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335042
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41619}
