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}
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}
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}
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 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 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}
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}
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}
Add media config for using environment monotonic timestamps (i.e. not UTC) in RTCStats constructor, and implemented the usage of the flag.
Bug: chromium:369369568
Change-Id: Ia93d048742c28af201164fe7b2152b791bb6d0b6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/363946
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Olov Brändström <brandstrom@google.com>
Cr-Commit-Position: refs/heads/main@{#43156}
This API should not modify the aspect ratio of the frame, e.g. if the
frame is 1280x720 and requested_resolution is 1280x360, the result
should be 640x360, not a streched out 1280x360 frame. The spec version
of this API calls this "maxWidth" and "maxHeight" which is the right
way to think about it rather than a forced width and height.
VideoAdapter continues to be used to apply adaptation restrictions, but
we now make sure to calculate the correct frame size BEFORE applying
restrictions. Prior to this CL, the VideoAdapter was also used to apply
requested_resolution restrictions. This is actually wrong and would
cause strange scaling factors in some cases, e.g. f=1280x720 + r=720x405
would result in 640x360 instead of 720x405. Now we make f=720x405 first
and only adjust further if restrictions or alignments require us to.
Since this is a change in behavior a WebRtcVideoChannelTest is updated.
Encodings integration test is also added, both for aspect ratio (new
behavior) and orientation agnosticism (old behavior still passing).
Bug: webrtc:366067962
Change-Id: I4e8dc27da5a84d73238b8ab74ef197eb5ee8072a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362101
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43020}
This allows detecting if it has been set reliably.
0 is a valid payload type.
Bug: webrtc:360058654
Change-Id: Ic3646abe20d0247592145ad27549fa46ddb7ec90
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362261
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#43016}
This requires making CallConfig move-only so it can hold a unique_ptr to
the factory, but as discussed with Danil, that seems fine.
Bug: chromium:355610792
Change-Id: Ie52e33faaa4a2af748daeb25f5327b7a532936e2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357862
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tony Herre <herre@google.com>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42679}
In preparation for upcoming changes in GetSimulcastConfig(), which will require a vector of stream resolutions instead of just the max resolution as an input, switch tests to use CreateEncoderStreams() instead of calling GetSimulcastConfig() directly.
Bug: webrtc:351644568, b/352504711
Change-Id: I541dd54a21a8b75028cff07a250f858a47898223
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357400
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42648}
Merge GetAndSetRtpSendParametersScaleResolutionDownByVP8, GetAndSetRtpSendParametersScaleResolutionDownByVP8WithOddResolution, GetAndSetRtpSendParametersScaleResolutionDownByH264 and GetAndSetRtpSendParametersScaleResolutionDownByH264WithOddResolution into one parameterized test.
PS. Not sure why we need separate tests for VP8 and H264. Underlaying code paths are codec agnostic as I can see.
Bug: webrtc:351644568, b/352504711
Change-Id: Ic95c59c1bfacdba8a42de8ecca9cab42014842e9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357360
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42646}
This is a cleanup of simulcast.cc. max_qp is not needed to decide simulcast config. Move setting of max QP in VideoStream one level up, to EncoderStreamFactory::CreateEncoderStreams(), where it can be set per stream.
Bug: webrtc:351644568, b/352504711
Change-Id: Ia0e3e9d90032383574dc8867b30d362e9c5df7e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357102
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42634}
This is a cleanup of simulcast.cc. bitrate_priority is not needed to decide simulcast config. Move setting of bitrate priority in VideoStream one level up, to EncoderStreamFactory::CreateEncoderStreams().
Bug: webrtc:351644568
Change-Id: I002d728ccf8d141fe4bbb32b390129ce57c830cd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357101
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42629}
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}
To allow various VideoBitrateAllocators to use propagated rather than global field trials
This relands the
https://webrtc-review.googlesource.com/c/src/+/349920
where patchset#1 is identical to the original change,
patchset#2 undoes (postpones) the expectation downstream propagates the Environment too.
Bug: webrtc:42220378
Change-Id: I4a9a32bb0926a875d37f3ba19dd5309e97546553
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/350364
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42298}
To allow various VideoBitrateAllocators to use propagated rather than global field trials
Bug: webrtc:42220378
Change-Id: I52816628169a54b18a4405d84fee69b101f92f72
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349920
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42288}
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}
To pass field trials to EncoderStreamFactory in FakeVideoSendStream and thus reduce dependency on the global field trial.
Bug: webrtc:10335
Change-Id: Iad32881c2d9158fe1d77f1b71f8d606374ea111e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/346340
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#42023}
describing video codecs with their parameters as static members of SdpVideoFormat:
static const SdpVideoFormat VP8();
static const SdpVideoFormat H264();
static const SdpVideoFormat VP9Profile0();
static const SdpVideoFormat VP9Profile1();
static const SdpVideoFormat VP9Profile2();
static const SdpVideoFormat VP9Profile3();
static const SdpVideoFormat AV1Profile0();
static const SdpVideoFormat AV1Profile1();
This removes the need to craft instances of these by hand.
BUG=webrtc:15703
Change-Id: I2171e08b48ec98f18424f53f3b5d6d148130532e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/337441
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41833}
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}
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}
This is a reland of commit 63d03f586bb668f72113b61030ec0930aa192010
Original change's description:
> Unify access to SDP codec parameters
>
> which come from the a=fmtp:<pt> lines in the SDP and were used as either
> std::map<std::string, std:string>
> with three aliases,
> cricket::CodecParameterMap
> SdpAudioFormat::Parameters
> SdpVideoFormat::Parameters
>
> Use webrtc::CodecParameterMap in all places.
>
> BUG=None
>
> Change-Id: If47692bde7347834c349c6539b43309d8770e67b
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330420
> Reviewed-by: Florent Castelli <orphis@webrtc.org>
> Reviewed-by: Harald Alvestrand <hta@webrtc.org>
> Commit-Queue: Philipp Hancke <phancke@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#41375}
Bug: None
Change-Id: I5f8f45688df232eb37b12fa3e56a893a1c754e17
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331402
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#41467}
which come from the a=fmtp:<pt> lines in the SDP and were used as either
std::map<std::string, std:string>
with three aliases,
cricket::CodecParameterMap
SdpAudioFormat::Parameters
SdpVideoFormat::Parameters
Use webrtc::CodecParameterMap in all places.
BUG=None
Change-Id: If47692bde7347834c349c6539b43309d8770e67b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330420
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#41375}
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}
