The rename ensures we don't confuse this implementation with
the new one based on the new dcSCTP library.
Bug: webrtc:12614
No-Presubmit: True
Change-Id: Ida08659bbea9c98aba8247d4368799ff7dd18729
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214482
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33688}
When migrating to use StrongAlias types, the PPID was incorrectly
modeled as an uint16_t instead of a uint32_t, as it was prior to using
StrongAlias. Most likely a copy-paste error from StreamID.
As the Data Channel PPIDs are in the range of 51-57, it was never caught
in tests.
Bug: webrtc:12614
Change-Id: I2b61ef7935df1222068e7f4e70fc2aaa532dcf7b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214960
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33687}
simplifying the code and comparing against the value libsrtp expects
and increase verbosity of error logging related to key length mismatches.
BUG=None
Change-Id: Icc0d0121d2983e23c95b0f972a5f6cac1d158fd7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213146
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <philipp.hancke@googlemail.com>
Cr-Commit-Position: refs/heads/master@{#33685}
VideoStreamEncoderTest: Remove unneeded set_timestamp_rtp in CreateFrame methods (the timestamp is set based on ntp_time_ms in VideoStreamEncoder::OnFrame).
Bug: none
Change-Id: I6b5531a9ac21cde5dac54df6de9b9d43261e90c6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214488
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Commit-Queue: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33683}
The Reassembly Queue receives fragmented messages (DATA or I-DATA
chunks) and - with help of stream reassemblers - will reassemble these
fragments into messages, which will be delivered to the client.
It also handle partial reliability (FORWARD-TSN) and stream resetting.
To avoid a DoS attack vector, where a sender can send fragments in a way
that the reassembly queue will never succeed to reassemble a message and
use all available memory, the ReassemblyQueue has a maximum size.
Bug: webrtc:12614
Change-Id: Ibb084fecd240d4c414e096579244f8f5ee46914e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214043
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33678}
This class handles the assembly of fragmented received messages (as DATA
chunks) and manage per-stream queues. This class only handles
non-interleaved messages as described in RFC4960, and is not used when
message interleaving is enabled on the association, as described in
RFC8260.
This is also only part of the reassembly - a follow-up change will add
the ReassemblyQueue that handle the other part as well. And an even
further follow-up change will add a "interleaved reassembly stream".
Bug: webrtc:12614
Change-Id: Iaf339fa215a2b14926f5cb74f15528392e273f99
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214042
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33677}
The Data Tracker's purpose is to keep track of all received DATA chunks
and to ACK/NACK that data, by generating SACK chunks reflecting its view
of what has been received and what has been lost.
It also contains logic for _when_ to send the SACKs, as that's different
depending on e.g. packet loss. Generally, SACKs are sent every second
packet on a connection with no packet loss, and can also be sent on a
delayed timer.
In case partial reliability is used, and the transmitter has decided
that some data shouldn't be retransmitted, it will send a FORWARD-TSN
chunk, which this class also handles, by "forgetting" about those
chunks.
Bug: webrtc:12614
Change-Id: Ifafb0c211f6a47872e81830165ab5fc43ee7f366
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213664
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33676}
Each file is a SCTP packet (without any additional headers), all
extracted from a few Wireshark dumps that have been manually recorded.
Bug: webrtc:12614
Change-Id: I64bef0c563f1d83ae22735d702c8abafec6429b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214701
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33675}
To maintain interoperability between different capturer implementations
this change updates WgcScreenSourceEnumerator to return a list of
device indices instead of a list of HMONITORs, and WgcScreenSource to
accept a device index as the input SourceId. WGC still requires an
HMONITOR to create the capture item, so this change also adds a utility
function GetHmonitorFromDeviceIndex to convert them, as well as new
tests to cover these changes.
Bug: webrtc:12663
Change-Id: Ic29faa0f023ebc26b4276cf29ef3d15d976e8615
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214600
Commit-Queue: Austin Orion <auorion@microsoft.com>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33673}
This CL fixes a buffer copying issue introduced in this CL:
https://webrtc-review.googlesource.com/c/src/+/196485
In the BasicDesktopFrame::CopyOf function, the src and dst params
were swapped. For me this manifested as a missing cursor when using
Chrome Remote Desktop. I don't know of any other bugs this caused
but I have to assume it affects all callers of the function given
that the copy will never occur.
Bug: chromium:1197210
Change-Id: I076bffbad1d658b1c6f4b0dffea17d339c867bef
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214840
Commit-Queue: Joe Downing <joedow@google.com>
Commit-Queue: Jamie Walch <jamiewalch@chromium.org>
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Cr-Commit-Position: refs/heads/master@{#33672}
There's been reports of dropped frames that are not counted and
correctly reported by getStats().
If a HW decoder is used and the system is provoked by stressing
the system, I've been able to reproduce this problem. It turns out
that we've missed frames that are dropped because there is no
callback to the Decoded() function.
This CL restructures the code so that dropped frames are counted
even in cases where there's no corresponding callback for some frames.
Bug: webrtc:11229
Change-Id: I0216edba3733399c188649908d459ee86a9093d0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214783
Commit-Queue: Johannes Kron <kron@webrtc.org>
Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33671}
This fuzzer explores the SCTP parsing, as well as the individual
chunks, as a successfully parsed packet will have its chunks iterated
over and formatted using ToString.
Bug: webrtc:12614
Change-Id: I88f703c5f79e4775a069b1d5439d413870f6a629
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214490
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33670}
The SdpOfferAnswerHandler::ssrc_generator_ variable is used from
multiple threads.
Adding thread checks + tests for UniqueNumberGenerator along the way.
Bug: webrtc:12666
Change-Id: Id2973362a27fc1d2c7db60de2ea447d84d18ae3e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214702
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33668}
Timer is a high-level timer (in contrast to the low-level `Timeout`
class). Timers are started and can be stopped or restarted. When a timer
expires, the provided callback will be triggered.
Timers can be configured to do e.g. exponential backoff when they expire
and how many times they should be automatically restarted.
Bug: webrtc:12614
Change-Id: Id5eddd58dd0af62184b10dd1f98e3e886e3f1d50
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213350
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33666}
This change adds support for emitting encoded frames
for recording when the decoder can't easily read out
encoded width and height as is the case for AV1 streams,
in which case the information is buried in OBUs. Downstream
project relies on resolution information being present for key
frames. With the change, VideoReceiveStream2 infers the
resolution from decoded frames, and supplies it in the
RecordableEncodedFrames.
Bug: chromium:1191972
Change-Id: I07beda6526206c80a732976e8e19d3581489b8fe
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214126
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Markus Handell <handellm@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33662}
It was recommened to me to move this define to the top level BUILD.gn
file to avoid potential issues with the define not being available
where we need it.
Bug: webrtc:9273
Change-Id: Id0e939a51d1e381f684a3ae970569a255f52a5bb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214101
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Austin Orion <auorion@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#33661}
The length field was validated to not be too big, or to have too much
padding, but it could be smaller than the fixed size of the chunk, which
isn't correct. Now it's enforced to be at minimum the size of the fixed
size header.
Bug: webrtc:12614
Change-Id: I57089a5ba2854eeb63ab3b4e28cf5878087d06e8
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214484
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33659}
Every chunk should be at least 4 bytes to be valid - that's the size of
the chunk header. If the embedded length was zero (0), iterating over
the chunks would never complete. Fixed now.
Bug: webrtc:12614
Change-Id: I1cbd070ad34a51584f6b09c5364c3db1b2bcdc2e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214483
Reviewed-by: Tommi <tommi@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33658}
StatsCollector::ExtractSessionInfo was run fully on the signaling thread
and several calls were being made to methods that need to run on the
network thread.
Additionally, BaseChannel::transport_name() was being read directly
on the signaling thread (needs to be read on the network thread).
So with shifting the work that needs to happen on the network thread
over to that thread, we now also grab the transport name there and
use the name with the work that still needs to happen on the signaling
thread.
These changes allow us to remove Invoke<>() calls to the network thread from
callback functions implemented in PeerConnection:
* GetPooledCandidateStats
* GetTransportNamesByMid
* GetTransportStatsByNames
* Also adding a correctness thread check to:
* GetLocalCertificate
* GetRemoteSSLCertChain
Because PeerConnection now has a way of knowing when things are
or have been uninitialized on the network thread, all of these
functions can exit early without doing throw away work.
Additionally removing thread hops that aren't needed anymore from
JsepTransportController.
Using the RTC_LOG_THREAD_BLOCK_COUNT() macro in GetStats, the number
of Invokes (when >1), goes down by 3. Typically from 8->5, 7->4, 6->3.
Bug: webrtc:11687
Change-Id: I06ab25eab301e192e99076d7891444bcb61b491f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214135
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33656}
WebRTC code has two ways of querying for the NTP time:
- rtc::TimeMillis() + NtpOffsetMs()
- Clock::CurrentNtpTime
`Clock::CurrentNtpTime` is not monotonic and is platform dependent.
This CL changes its implementation return `rtc::TimeMillis() +
NtpOffsetMs()`
More info is available in the attached bug.
Bug: webrtc:11327
Change-Id: I34fe4cc2d321c2b63275c93be21122c9de1ab403
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213425
Commit-Queue: Paul Hallak <phallak@google.com>
Reviewed-by: Minyue Li <minyue@webrtc.org>
Reviewed-by: Henrik Andreassson <henrika@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33655}
This also deletes unused method has_channels() and moves us closer
to having the ChannelManager just be a factory class. Once we get there
the ownership of the channels themselves can be with the classes that
hold pointers to them. Today the initialization and teardown of those
classes need to be synchronized with ChannelManager. But there's no
real value in keeping the channel pointers owned elsewhere.
Places where we have naked un-owned channel pointers:
* RtpTransceiver for voice and video
* PeerConnection::data_channel_controller_ (rtp data channel)
Bug: webrtc:11994
Change-Id: Id6df27414cc57b6ecf0f7f769fdb9603ed114bfd
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214440
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33654}
As this library will only use StrongAlias types for all its
sequence numbers, the UnwrappedSequenceNumber class should use those
types and not the primitive underlying types (e.g. uint32_t).
This makes e.g. Unwrap() return a strong type, which is preferred.
Bug: webrtc:12614
Change-Id: Icd0900c643a1988d1a3bbf49d87b4d4d1bbfbf1f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213663
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33651}
The RTCReceivedRtpStreamStats hierarchy, which inherit from
RTCRtpStreamStats, already contain members ssrc, kind, codec_id and
transport_id so there's no need to list them inside
RTCRemoteInboundrtpStreamStats.
This CL removes duplicates so that we don't DCHECK-crash on Android,
and adds a unit test ensuring we never accidentally list the same
member twice.
Bug: webrtc:12658
Change-Id: I27925eadddc6224bf6d6a91784ed7cafd7a4cfb3
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214343
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33649}
Clients will use this API for all their interactions with this library.
It's made into an interface (of which there will only be a single
implementation) simply for documentation purposes. But that also allows
clients to mock the library if wanted or to have a thread-safe wrapper,
as the library itself is not thread-safe, while keeping the same
interface.
Bug: webrtc:12614
Change-Id: I346af9916e26487da040c01825c2547aa7a5d0b7
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213348
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33648}
This reverts commit 5a40b3710545edfd8a634341df3de26f57d79281.
Reason for revert: Fixed the bug and ran layout tests.
Original change's description:
> Revert "Use the new DNS resolver API in PeerConnection"
>
> This reverts commit acf8ccb3c9f001b0ed749aca52b2d436d66f9586.
>
> Reason for revert: Speculative revert for https://ci.chromium.org/ui/p/chromium/builders/try/win10_chromium_x64_rel_ng/b8851745102358680592/overview.
>
> Original change's description:
> > Use the new DNS resolver API in PeerConnection
> >
> > Bug: webrtc:12598
> > Change-Id: I5a14058e7f28c993ed927749df7357c715ba83fb
> > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/212961
> > Reviewed-by: Niels Moller <nisse@webrtc.org>
> > Commit-Queue: Harald Alvestrand <hta@webrtc.org>
> > Cr-Commit-Position: refs/heads/master@{#33561}
>
> # Not skipping CQ checks because original CL landed > 1 day ago.
>
> TBR=hta@webrtc.org
>
> Bug: webrtc:12598
> Change-Id: Idc9853cb569849c49052f9cbd865614710fff979
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/213188
> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#33591}
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: webrtc:12598
Change-Id: Ief7867f2f23de66504877cdab1b23a11df2d5de4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214120
Commit-Queue: Harald Alvestrand <hta@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33647}
Done in preparation for the child CL which adds an alternative
implementation.
Bug: webrtc:7494
Change-Id: I4963376afc917eae434a0d0ccee18f21880eefe0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214125
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Alessio Bazzica <alessiob@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33646}
The RemoteAudioSource has an AudioDataProxy that acts as a sink, passing
along data from AudioRecvStreams to the RemoteAudioSource. If an SSRC is
changed (or other reconfiguration happens) with SDP, the recv stream and
proxy get recreated.
In Plan B, because remote tracks maps 1:1 with SSRCs, it made sense to
end remote track/audio source in response to this. In Plan B, a new
receiver, with a new track and a new proxy would be created for the new
SSRC.
In Unified Plan however, remote tracks correspond to m= sections. The
remote track should only end on port:0 (or RTCP BYE or timeout, etc),
not because the recv stream of an m= section is recreated. The code
already supports changing SSRC and this is working correctly, but
because ~AudioDataProxy() would end the source this would cause the
MediaStreamTrack of the receiver to end (even though the media engine
is still processing the remote audio stream correctly under the hood).
This issue only happened on audio tracks, and because of timing of
PostTasks the track would kEnd in Chromium *after* promise.then().
This CL fixes that issue by not ending the source when the proxy is
destroyed. Destroying a recv stream is a temporary action in Unified
Plan, unless stopped. Tests are added ensuring tracks are kLive.
I have manually verified that this CL fixes the issue and that both
audio and video is flowing through the entire pipeline:
https://jsfiddle.net/henbos/h21xec97/122/
Bug: chromium:1121454
Change-Id: Ic21ac8ea263ccf021b96a14d3e4e3b24eb756c86
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214136
Commit-Queue: Henrik Boström <hbos@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33645}
