This is a reland of commit 3afb8e2431
Patchset 1 is the original CL. Patchset 2 contains a fix:
Depending on call site, the number of spatial layers for VP9 might be
signalled in three different ways. One of them was afaict only used in
out perf tests, and resulted in the max bitrate being incorrectly
capped.
The fix now checks that field too.
Original change's description:
> When VP9 SVC is used, use SvcConfig to set max bitrate for the stream.
>
> Currently, a default max bitrate is determined within WebRtcVideoEngine,
> which maxes out at 2.5Mbps - and that limits the max bitrate deteremined
> by SvcConfig for resolutions above 720p.
>
> This does not affect simulcast, as WebRtcVideoEngine already knows to
> trust the rate allocation in simulcast.cc instead.
>
> Bug: webrtc:14017
> Change-Id: I0c310a6fd496e9e5a10eae45838900068aa1ae2d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267160
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37370}
Bug: webrtc:14017, webrtc:14234
Change-Id: Idcaf4321a20c917e4049522c577336ddcfc7ffbb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267860
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37446}
This reverts commit 3afb8e2431.
Reason for revert: Causes some unexpected perf regressions.
Original change's description:
> When VP9 SVC is used, use SvcConfig to set max bitrate for the stream.
>
> Currently, a default max bitrate is determined within WebRtcVideoEngine,
> which maxes out at 2.5Mbps - and that limits the max bitrate deteremined
> by SvcConfig for resolutions above 720p.
>
> This does not affect simulcast, as WebRtcVideoEngine already knows to
> trust the rate allocation in simulcast.cc instead.
>
> Bug: webrtc:14017
> Change-Id: I0c310a6fd496e9e5a10eae45838900068aa1ae2d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267160
> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#37370}
Bug: webrtc:14017
Change-Id: I1e45ee3f78deb50a9057d648146b1a6360782aa3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267800
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37438}
Currently, a default max bitrate is determined within WebRtcVideoEngine,
which maxes out at 2.5Mbps - and that limits the max bitrate deteremined
by SvcConfig for resolutions above 720p.
This does not affect simulcast, as WebRtcVideoEngine already knows to
trust the rate allocation in simulcast.cc instead.
Bug: webrtc:14017
Change-Id: I0c310a6fd496e9e5a10eae45838900068aa1ae2d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/267160
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37370}
It's normal for a receiver to not be configured to receive, such as when
currentDirection is not (or not yet) "sendrecv" or "recvonly".
getParameters() returning an empty set of encodings is valid and these
logs are not very useful. It's also inconsistent that we only log after
SLD has happened due to different code paths inside getParameters(),
repro: https://jsfiddle.net/henbos/xqksj3wd/.
Most notably we're calling getParameters() internally from inside of
getStats() which can cause excessive log spam. I prefer that we remove
these logs rather than avoid calling getParameters() from inside of
getStats() on non-receiving receivers since it's valid to check how many
encodings exist on a receiver using getParameters(), and whether or not
the SSRC has been signaled could in theory affect the number of
encodings even if we do want to receive. Also an app calling
getParameters() on an inactive receiver is valid and should not cause
logs.
Bug: webrtc:14225
Change-Id: I4290781d6aed92aa03fe0c662762aa97c99a045c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/266960
Commit-Queue: Erik Språng <sprang@webrtc.org>
Auto-Submit: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37335}
increasing precision since summing up rounded values leads to
a rounding error, in particular for small frames which take very
little time to decode.
BUG=webrtc:12526,webrtc:13756
Change-Id: I647c702808856a002c746ed9f115aa9bcaddc1f3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262810
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/main@{#37249}
This cl/ adds a way of setting an EncoderSelector on a specific
RtpSenderInterface. This makes it possible to easily use different
EncoderSelector on different streams within the same or different PeerConnections.
The cl/ is almost identical to the impl. of RtpSenderInterface::SetFrameEncryptor.
Iff a EncoderSelector is set on the RtpSender, it will take precedence
over the VideoEncoderFactory::GetEncoderSelector.
Bug: webrtc:14122
Change-Id: Ief4f7c06df7f1ef4ce3245de304a48e9de0ad587
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264542
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37150}
Setting the transport cc flag was only possible post creation for
audio receive streams, while video receive streams need to be recreated.
This CL moves the setter for transport_cc() to where the getter is and
adds boiler plate implementations for the video streams. For audio
streams this splits "SetUseTransportCcAndNackHistory" into two methods,
SetTransportCc and SetNackHistory.
Bug: none
Change-Id: Idbec8217aef10ee77907cebaecdc27b4b0fb18e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264443
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37038}
This is part of the project to delete the class entirely.
The CL also adds an "use_rtx" parameter to the function for listing
video codecs, rather than filtering those away afterwards.
Bug: webrtc:13931
Change-Id: I96b9b18c694a1c0986ccf22face76ef4c704d372
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262666
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36963}
Step one in making it a separate type, that will be done as a
followup, after downstream code is updated to use the new name.
Bug: webrtc:11607
Change-Id: I6fa664a0729b1cfd71b7f02b6441880beee0e741
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262806
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36946}
implements a total frame assembly time statistic that measures the
cumulative time between the arrival of the first packet of a frame
(the lowest reception time) and the time all packets of the frame have
been received (i.e. the highest reception time)
This is similar to totalProcessingDelay
https://w3c.github.io/webrtc-stats/#dom-rtcinboundrtpstreamstats-totalprocessingdelay
in particular with respect to only being incremented for frames that are being decoded but does not include the amount of time spent decoding the frame.
This statistic is useful for evaluating mechanisms like NACK and FEC
and gives some insight into the behavior of the pacer sending the
packets.
Note that for frames with just a single packet the assembly time will be zero. In order to calculate an average assembly time an additional frames_assembled_from_multiple_packets counter for frames with more than a single packet is added.
Currently this is a nonstandard stat so will only show up in webrtc-internals and not in getStats. Formally it can be defined as
totalAssemblyTime of type double
Only exists for video. The sum of the time, in seconds, each video frame takes from the time the first RTP packet is received (reception timestamp) and to the time the last RTP packet of a frame is received.
Given the complexities involved, the time of arrival or the reception timestamp is measured as close to the network layer as possible.
This metric is not incremented for frames that are not decoded, i.e., framesDropped, partialFramesLost or frames that fail decoding for other reasons (if any). Only incremented for frames consisting of more than one RTP packet. The average frame assembly time can be calculated by dividing the totalAssemblyTime with framesAssembledFromMultiplePacket.
framesAssembledFromMultiplePacket of type unsigned long
Only exists for video. It represents the total number of frames correctly decoded for this RTP stream that consist of more than one RTP packet.
For such frames the totalAssemblyTime is incremented.
BUG=webrtc:13986
Change-Id: Ie0ae431d72a57a0001c3240daba8eda35955f04e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260920
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Henrik Boström <hbos@webrtc.org>
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36922}
VP9 automaticResizeOn is disabled if more than one spatial layer is configured via scalability mode.
Bug: webrtc:13960
Change-Id: I7c6351bca6d2f32bcc7391894e8dcc9e74ca2050
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261315
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36897}
This reverts commit 16a8b25d80.
Reason for revert: Checking if this is blocking the Chromium autoroller.
Original change's description:
> Update local_ssrc without needing to recreate video streams.
>
> This is comparable to this change done previously for for audio streams:
> https://webrtc-review.googlesource.com/c/src/+/222042
>
> Bug: webrtc:11993
> Change-Id: Ic953f816a8f7c56d1c3dc9a16d85bef3696a663d
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261960
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36876}
Bug: webrtc:11993
Change-Id: I3a8d2f6a7e89b6784754d8e891a4e01479807c2d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262422
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#36892}
GetRtpExtensions() is still used in one corner case for audio receive
streams, so GetRtpExtensions has migrated to AudioReceiveStream.
Updated FlexfecReceiveStream config management (incl. pass by value) and
now store an RtpHeaderExtensionMap in FlexfecReceiveStreamImpl.
Call GetRtpExtensionMap() from call.cc instead of constructing one on
the fly for each rtp packet (for video packets at least).
Bug: webrtc:11993
Change-Id: Id90ec5d43ea368f58edd6f17cb39d8c54aec641f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261800
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36839}
This is to avoid accessing the array via the config struct.
Moving forward we might want to consider using the RtpHeaderExtensionMap
instead of a std::vector of RtpExtension.
Bug: webrtc:11993
Change-Id: I8469dbbd9bb95a69f87b5912bfc4bf8b8f603beb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261317
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36820}
`remote_ssrc` can be considered const while some other state represented
by rtp_config() can not and also is tied to a specific thread.
Separating access to these variables, makes moving things around easier.
Bug: webrtc:11993
Change-Id: I70aa000daab6174a401e01dca163213174e8f284
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261316
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36818}
Intended to let Vp8TemporalLayersFactory (an api/ target) reuse
this function, without depending on the codec implementation, and
without introducing a dependency cycle with the webrtc_vp8 build
target.
Bug: webrtc:11607
Change-Id: I671422e994e1005da8c7d768e8dd8ff795553e51
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261308
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36816}
This reverts commit 45361f78ed.
Reason for revert: Perf alerts galore.
Original change's description:
> Calculate video stream max bitrate using expression.
>
> This replaces the ealier table-based caps.
> Apart from the VGA cap (now 1600kbps instead of 1700kbps), or if using
> "in between" resolutions, the caps are unchanged - but now cover high
> resolutions better.
>
> Bug: webrtc:14017
> Change-Id: I8649b528495d6c917e38ea8cb1a272df6c464c03
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260940
> Commit-Queue: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#36776}
Bug: webrtc:14017
Change-Id: I18ebc81c6054713c58d49bd227e37090686958c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261309
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#36794}
This replaces the ealier table-based caps.
Apart from the VGA cap (now 1600kbps instead of 1700kbps), or if using
"in between" resolutions, the caps are unchanged - but now cover high
resolutions better.
Bug: webrtc:14017
Change-Id: I8649b528495d6c917e38ea8cb1a272df6c464c03
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260940
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36776}
Recent Clang versions have enhanced -Wunused-but-set-variable which now
warns about this.
Bug: chromium:1309955
Change-Id: Ie70df85f5a6d2cbabb4e10960bfd926ff7bf32cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/257162
Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Cr-Commit-Position: refs/heads/main@{#36381}
`enable_non_sender_rtt_` is updated a few lines below.
This seems to have been missed in the code review.
Bug: webrtc:12951, webrtc:13853
Change-Id: Idc06421362f6b2d831b5a828f296142aab9a46e1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256860
Reviewed-by: Sam Zackrisson <saza@webrtc.org>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Ivo Creusen <ivoc@webrtc.org>
Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36380}
This patch takes a stab at modules/video_coding,
but reaches only about half.
Bug: webrtc:10335
Change-Id: I0d47d0468b818145470c51ae4e8e75ff58d499ae
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/256112
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36335}
Motivation: never used.
Follow-up CL of https://webrtc-review.googlesource.com/c/src/+/250680.
Tested on a custom chromium build by making a video call and with
keyboard activity. The expected logs from the APM transient suppressor
sub-module were shown.
Bug: webrtc:11226
Change-Id: I4186994412dd8ba2e71ed8f9dcc9cf8f8e40fbd3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/250667
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Björn Terelius <terelius@webrtc.org>
Reviewed-by: Gustaf Ullberg <gustaf@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36300}
