As the synchronous version only posts a task to recreate the encoder
later, it is not possible to catch errors and state changes that
could appear then.
The asynchronous version of SetParameters() aims to solve this by
providing a callback to wait for the completion of the encoder
reconfiguration, allowing any error to be propagate and subsequent
getParameters() call to have up to date information.
Bug: webrtc:11607
Change-Id: I5548e75aa14a97f8d9c0c94df1e72e9cd40887b2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278420
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38627}
The code for determining outbound-rtp.active assumed, as the spec says,
that we have one RtpEncodingParameters per RTP stream. Unfortunately
SVC is currently implemented as one RtpEncodingParameters per SVC
layer. This causes a discrepency where we do correctly only have one
outbound-rtp stats object, but the lookup to check whether or not we are
"active" needs to look at more than a single encoding.
The bug is that if SVC layers are {inactive, active, active} then
stats reports outbound-rtp.active: false. With this fix, active: true is
reported if ANY of the SVC layers are active.
For singlecast or simulcast this CL has no change in behavior. In these
cases we have the same number of outbound-rtp and encodings and a simple
ssrc lookup does work.
The fix is exercised by unit tests and has also manually been confirmed:
- Singlecast tested by https://jsfiddle.net/henbos/nvd6p4j1/.
- Simulcast tested by https://crbug.com/webrtc/14628#c11.
- SVC tested by Google Meet and chrome://webrtc-internals/.
Bug: webrtc:14628
Change-Id: Ib89945caf29c8f4b85dd8a1120dcf8279296e4a3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/282222
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38569}
and do the resolution of rids to layers. This has no effect yet
since the simulcast encoder adapter (SimulcastEncoderAdapter::Encode), the VP8 encoder (LibvpxVp8Encoder::Encode) and the OpenH264 encoder (H264EncoderImpl::Encode) all generate a key frame for all layers whenever a key frame is requested on one layer.
BUG=chromium:1354101
Change-Id: I13f5f1bf136839a68942b0f6bf4f2d5890415250
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280945
Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38565}
These metrics were not only non-standard, but residing in the
non-standard "track" stats object that we want to delete. As per
https://github.com/w3c/webrtc-stats/issues/695#issuecomment-1259611462
these metrics are no longer needed because we already have
inbound-rtp.totalInterFrameDelay/totalSquaredInterFrameDelay which is
basically the same thing.
// mac_rel infra failures are unrelated
NOTRY=True
Bug: webrtc:14522
Change-Id: I565da42514a93f15532ba8357dd006547a5296ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/278100
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38509}
This metric was always supposed to be the spec's answer to
googBucketDelay, and is defined as "The total number of seconds that
packets have spent buffered locally before being transmitted onto the
network." But our implementation measured the time between capture and
send, including encode time. This is incorrect and yields a much larger
value than expected.
This CL updated the metric to do what the spec says. Implementation-wise
we measure the time between pushing and popping each packet from the
queue (in modules/pacing/prioritized_packet_queue.cc).
The spec says to increment the delay counter at the same time as we
increment the packet counter in order for the app to be able to do
"delta totalPacketSendDelay / delta packetSent". For this reason,
`total_packet_delay` is added to RtpPacketCounter. (Previously, the
two counters were incremented on different threads and observers.)
Running Google Meet on a good network, I could observe a 2-3 ms average
send delay per packet with this implementation compared to 20-30 ms
with the old implementation. See b/137014977#comment170 for comparison
with googBucketDelay which is a little bit different by design -
totalPacketSendDelay is clearly better than googBucketDelay.
Since none of this depend on the media kind, we can wire up this metric
for audio as well in a follow-up:
https://webrtc-review.googlesource.com/c/src/+/280523
Bug: webrtc:14593
Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38480}
defined in
https://w3c.github.io/webrtc-encoded-transform/#rtcrtpsender-extension
Note: this does not implement the "rid(s)" parameter which will be done in a future CL.
VP8 still synchronizes keyframes on all layers even when asked for ones on individual layers while H264 (when implemented as three different encoders in SimulcastEncoderAdapter) can actually utilize this.
This does not change the behavior when receiving a RTCP PLI for a particular layer.
BUG=chromium:1354101
Change-Id: Ic8b14d155242e32c9aeafa55fe6652f346ac76b8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274169
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#38472}
ScalabilityMode should be validated against the currently
allowed codecs or the currently used codec.
Bug: webrtc:11607
Change-Id: Id2e6cbfad4f089de450150e1203657ed316e2f29
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277403
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38433}
This cl/ changes so that the EncoderStreamFactory is
not created inside WebRtcVideoSendStream (webrtc_video_engine).
The benifit of this is that the VideoStreamEncoder can then
amend the EncoderStreamFactory with state (and types)
w/o exposing it in VideoEncoderConfig.
I.e as an alternative to changes done inside
https://webrtc-review.googlesource.com/c/src/+/276742.
The fake_webrtc_call is modified to (if needed) create
it's own EncoderStreamFactory if needed.
Note: this cl/ will have to be merged with with
https://webrtc-review.googlesource.com/c/src/+/277002.
Bug: webrtc:14451
Change-Id: I3d896b227d39725ba6409622e8d09d14bd45d5fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/277160
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38237}
This cl/ is a NOP refactoring,
moving the EncoderStreamFactory from within webrtc_video_engine.cc
into own file in video/. simulcast.cc is collateral.
Bug: webrtc:14451
Change-Id: Ia69b9241d8cd8a12be6628d887701f2e244c07cc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276861
Reviewed-by: Artem Titov <titovartem@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#38224}
This moves the ownership away from VideoReceiveStream2 and closer to
VCMDecoderDataBase. That facilitates unregistration (upcoming change)
without recreating receive streams.
Bug: none
Change-Id: I812175134730a0ffbf7077fd149c8489481c73d8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272481
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37866}
A follow-up change will combine the setters for ulpfec and red payload
types, since they're entwined.
Bug: webrtc:11993
Change-Id: Ifea7fe9f4ebc7ac88a62db6cd6748f4d3c20db4c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271482
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37785}
This allows for `config_.rtp.nack.rtp_history_ms` to be modified
without deleting and recreating video receive streams.
Bug: webrtc:11993
Change-Id: I8ba132b22fe0e6de03d1c42fc38a570cbe138817
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269301
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37701}
By attaching the sink when all is set up, we make it possible for an
application to listen for that event - and only then start producing
frames. Otherwise frames risk being dropped during the setup phase.
Bug: webrtc:14276
Change-Id: I0a906681fc526b0ee88c60a842afb0d68e21de14
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/270660
Auto-Submit: Erik Språng <sprang@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37696}
...to allow for turning on/off loss notifications for video receive
streams without tearing down and recreating the whole stream.
Bug: webrtc:11993
Change-Id: Ia961bd343ce816ffe3414f11e3a58bb3c235307c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269252
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37688}
This is a step towards getting rid of reconfiguration via tearing down
and reconstructing receive streams when parts of the configuration
change at runtime.
Bug: webrtc:11993
Change-Id: I337e523f17805b75826ddbd75bd3d0eb6e910bd8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269250
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37680}
...for payload type changes and avoid recreating the main video stream.
Bug: webrtc:11993
Change-Id: I03e44ff25d88caeb082a2e44b2e802d3b9392feb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269244
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37666}
This reduces the number of times we recreate video receive streams
and prepares for not having to do that for flexfec streams and avoid
having to recreate a video receive stream when flexfec config changes.
Bug: webrtc:11993
Change-Id: I11134b6a72eb162623ebbc12521d409da8616107
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261941
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37641}
instead of using Lock/Unlock attributes, use Assert attribute to annotate code is running on certain task queue or thread.
Such check better matches what is checked, in particular allows to
recheck (and thus better document) currently used task queue
Bug: None
Change-Id: I5bc1c397efbc8342cf7915093b578bb015c85651
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269381
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37619}
`stream_` will always be non-null when SetRecvParameters is called.
For the flexfec stream, the condition won't happen since `IsCompleteAndEnabled` doesn't consider `rtp.extension` state.
As is, this code just adds apparent complexity to SetRecvParameters.
Bug: none
Change-Id: Ie2386905bd8a338669629c7bc5f0abb39bd36d22
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/269245
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Auto-Submit: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37597}
SetFeedbackParameters no longer recreates the embedded streams for:
- transport cc flag
- rtcp status
Bug: none
Change-Id: If6117a1ae760ca9a02f06bbfa2b46c6e0f448cfc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/268281
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37526}
This is a reland of commit 3afb8e24311dc1297150d4011894b6cb00841735
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 3afb8e24311dc1297150d4011894b6cb00841735.
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}
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}
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}
