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}
instead of throwing an error when trying to pick a send codec.
BUG=webrtc:15145,webrtc:4957
Change-Id: I056b145c093348576e1aeaf5def50d5414f2de70
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330122
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41360}
kDefaultQpMax=56 was defined in multiple places. Move it to media_constants and split it into two: VPx/AV1 and H26x values. H26x value is set to 51 which is the max bitstream QP value for H264/5.
This CL is expected to be a no-op because:
1. VideoCodec::qpMax value has not changed for VP8/9 and AV1.
2. VideoCodec::qpMax is currently not used by OpenH264 wrapper (wiring it up is out-of-scope of this CL).
3. Previous default qpMax=56 exceeded the max value for H26x (=51). External HW H26x encoders likely clamped it and used 51.
Bug: webrtc:14852
Change-Id: I1d795e695dac5c78e86ed829b24281e61066f668
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324282
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40997}
In some very high-bandwidth application there have been observations of
packet loss in the socket implementation (not on the network itself) due
to large bursts of packets arriving. Allocating too big buffers can of
course lead to issue as well, so this flag is intended to find a good
tradeoff.
Bug: webrtc:15585
Change-Id: I63eccb1a9f34d852d80c286fc27bffd17818f0ef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324021
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40963}
Because of our asymmetrical codec situation, it's possible to have
send only codecs that we cannot negotiate even with ourselves.
This means that we should not have a DCHECK, but just a plain error.
Bug: webrtc:15064
Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#40939}
