This is the first CL out of three to make the low-latency stream signaling
explicit. At the moment this is done by setting the render time to 0.
There's a dependency between Chromium and WebRTC which is why this is
split into three CLs to not break any existing functionality.
Bug: chromium:1327251
Change-Id: Ie6b268746d587a99334485db77181fb2c6e9b567
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264502
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37225}
In FrameBuffer3Proxy, if the stream became undecodable for a long
period of time and during this period the FPS changed,
the render times and decode delays would stray and cause
video pauses. This was because FrameBuffer3Proxy only updated the rtp
timestamp extrapolator on each new decodable temporal unit, rather than
each new frame.
Bug: webrtc:14168
Change-Id: I67a2c9ea392d24f84e82aa04f8c3076de11732af
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265388
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37201}
When a large queue of frames builds up due to a lost frame, the decode
delay can sometimes become quite large. In this case the stream may
signal as timed out when in fact it is not. Instead, the delay should
be capped at the timeout limit.
Bug: webrtc:14168
Change-Id: I5b4e8851b2c6d7d27a698627dc1633931d7fc00e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/265404
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37199}
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}
FrameBuffer3Proxy and sync decoding has been shown to work. First step of cleaning up is to remove the FrameBuffer2Proxy.
Change-Id: Ic96303c2d4f9111cfeed9927e8826ea7ffe7ee17
Bug: webrtc:14003
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264126
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37086}
Code that is probably bogus and causes frequent down-adaptation on
dual core systems was identified. We wish to remove this code in a
safe way. This CL achieves this under kill switch
WebRTC-MacSpecialOveruseRulesRemovalKillSwitch.
Fixed: webrtc:14138
Change-Id: Idf53348c8e1dc032d8eea58f626f91456d72ecb4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/264423
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Auto-Submit: Markus Handell <handellm@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#37043}
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}
When MediaStreamVideoSource::RequestRefreshFrame is called, the
capturer most often emits a refresh frame. Due to various
conditions such as for example timing of prior delivery,
these frames can be dropped at various places in the input
pipeline into WebRTC.
This change ensures the frame cadence adapter repeatedly
requests refresh frames at max fps frequency until one is
received, in which case the requests cease.
Fixed: chromium:1324120
Change-Id: I90f85d31b132b6c441aa1c28c5eff85e3dc365ad
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263520
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36998}
There are two cases that can be confusing for applications developers
which may result in the playout delay not being set as intended.
First, it is not well defined which min playout delay should be used
when multiple are set. This changes adds a warning to alert application
developers that they are setting multiple playout delays.
Second, if the playout delay header extension is used, developers must
be careful that the max playout delay is always larger than the min
playout delay, otherwise the behaviour is undefined. This change logs an
error when this case is detected.
Bug: None
Change-Id: I8477d48ef64636da080792362fa898e42f038bef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/263202
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36977}
Putting these classes in a sub folder increases
structure and clarifies that they are used as
helper classes. Affected classes in this change:
* CodecTimer
* InterFrameDelay
* RttFilter
VCMTiming will be moved in a separate CL.
Additional changes:
* Remove VCM prefix from class names.
* Introduce granular BUILD.gn targets.
* Update some includes.
Bug: webrtc:14111
Change-Id: Ia75128aa955a819033b97d4784cb61904de7230b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262960
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36975}
This helper class currently lives in `modules/video_coding`,
but it's only users are in `video/`. Thus, it makes sense to
move the class to `video/`.
Bug: webrtc:14116
Change-Id: I0d3f8961bc8f5fe80f3100dbbd309b206020e6d5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262963
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Rasmus Brandt <brandtr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36973}
In case the encoder TQ has been stopped and doesn't accept more tasks,
we could end up in a hung state during Stop(). This is a hypothetical
situation, but can be simulated in a test and avoided.
Bug: webrtc:14063
Change-Id: I20f48b11b6266f6875ed5e69de3529212505e439
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258125
Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36964}
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}
The new TaskQueuePacedSender has been default-on in code since M97, and
there are no further usages of it that I can find. Let's clean this up!
The PacingController and associated tests will be cleaned up in a
follow-up cl.
Bug: webrtc:10809
Change-Id: I0cb888602939add953415977ee79ff0b3878fea5
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/258025
Reviewed-by: Per Kjellander <perkj@webrtc.org>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36890}
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}
Instead offer accessors for the specific config values from the struct
that are needed at different times. The remote_ssrc and rtx_ssrc
properties maybe accessed from any thread, other properties have
stricter requiremets.
Bug: webrtc:11993
Change-Id: I3ff8527b13452c773fae1b2574f1e3fd2583b481
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261319
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36823}
