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}
To make it usable in tests without depending on all of CallTest.
Bug: None
Change-Id: Ie3102ab71bcfe3862dd6c35d3285098e961e54df
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262807
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36932}
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}
This is comparable to this change done previously for for audio streams:
https://webrtc-review.googlesource.com/c/src/+/222042
This is a reland of commit 16a8b25d809e4d4982f9fc4b4e973acd506b8bca
with an additional fix in Patchset 2. Another problem turned out to be
in RTCPReceiver, which is fixed in:
https://webrtc-review.googlesource.com/c/src/+/262663
Bug: webrtc:11993
Change-Id: I63c7cf62a6dd50f88b491fea3ba866697552ef5f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/262665
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36907}
This reverts commit 16a8b25d809e4d4982f9fc4b4e973acd506b8bca.
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}
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}
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}
It defined RTC_PRIuS, which was needed for compatibility with MSVC
prior to version 2015.
Bug: webrtc:6424
Change-Id: I5668d473376201cad3e8da65927c967fc397804b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261314
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36814}
* Paramaterize VideoReceiveStream2Test to have variations that run with
and without a metronome.
* Migrate over tests to ensure frame timing is used.
Bug: webrtc:14003
Change-Id: Icccc2f0d548aaa64c50e010056e1e651174e02fa
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260942
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36812}
The webrtc::VideoStreamDecoderInterface was basically created as a public version of FrameBuffer2, but to hide the complexity of FrameBuffer2 it was also combined with decoding so that the public API could be reasonably simple to use. FrameBuffer3 has a simple API with a clear purpose, so its API can be exposed directly.
Bug: webrtc:14026
Change-Id: I81dc84b869e4d16c5e02feb5c876fbcede3d4a25
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/261181
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36781}
The field trial will remain as a kill-switch for a few weeks while
decisions about sync decoding are being made.
Change-Id: I6034d25a129404e94ab8830f51e83667e285c785
Bug: webrtc:14003
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260327
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36760}
video_stream_decoder2 is the only one used.
Change-Id: Iabee3521b2946f097296cf2b02025aa6e41e87a4
Bug: webrtc:11489
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260282
Commit-Queue: Evan Shrubsole <eshr@webrtc.org>
Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36692}
