With a previous refactoring, which made the data tracker responsible for
ensuring that the reassembly queue doesn't see any duplicate received
chunks, it no longer needs to know the initial peer's TSN. Removing.
Bug: None
Change-Id: I0e2aef1de0293f1860b46dee0089757c9c300aea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345701
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41997}
While an empty realm attribute is technically allowed, it reduces
the amount of entropy that goes into the turn credentials hash.
This remains technically broken in the implementation as hash_ is
not recomputed when changing the realm from the initial empty string
value to the empty string. Before this change this lead to hash_ not
being set and the allocate request being treated as not having
enough details to authenticate, resulting in an endless loop of packets.
BUG=chromium:329978076
Change-Id: I3d1295f905a9fb58ca5bc6f82466896f79031865
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344820
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Philipp Hancke <phancke@meta.com>
Reviewed-by: Christoffer Dewerin <jansson@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41996}
This code was moved to ReassemblyQueue::AddReassembledMessage, the build
file was updated to remove the source file, but the source file was
never actually deleted. Dead code.
Bug: None
Change-Id: Iafb9bb276ff870398a76737ceb16ffc50a91738e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345620
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41994}
The predefined SdpVideoFormats were not used everywhere,
which caused a discrepancy between send/receive capabilities
for AV1. This CL solves the immediate problems by making sure
send/receive capabilities for AV1 are reported the same way.
Fixed: chromium:331565934
Change-Id: I073091b7b5f987c7f434c17276fd84047ec723c2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344681
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Commit-Queue: Johannes Kron <kron@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41991}
This code looked a bit weird before this CL - probably because of old
refactorings.
In JsepTransport constructor, there is a DCHECK assuring that the RTP
DTLS transport is always present, so it can be passed directly to the
SctpTransport constructor, which avoids having the SetDtlsTransport
method in it.
Also, in the SctpTransport constructor, there was code that would set
the SCTP transport state to `kConnecting` if the DTLS transport was
present, but that was dead code, as it was always `nullptr` inside the
constructor before this CL. With this CL, it's always present, and the
SCTP Transport's state will initially always be `kConnecting` now. Which
is a step to deprecating the `kNew` state that doesn't exist in
https://w3c.github.io/webrtc-pc/#dom-rtcsctptransportstate.
One test case was modified, as it didn't test the reality. The test
created a SctpTransport, registered an observer, and added the DTLS
transport, and expected to receive a "statechange" from `kNew` (which is
not a state that exists in the spec) to `kConnecting`. If the test had
tested the opposite ordering - adding the DTLS transport first, and then
adding an observer, it wouldn't have experienced this. And since in
reality (with the implementation of JsepTransport before and
after this CL), it always adds the DTLS transport before any observer is
registered. So it wouldn't ever be fired, outside of tests.
Bug: webrtc:15897
Change-Id: I6ac24e0a331b686eb400fcf388ece50f2ad46a32
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/345420
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41987}
This CL updates H26xPacketBuffer to store and prepend SPS and PPS for
H.264 bitstreams when IDR only keyframe is allowed.
Bug: webrtc:13485
Change-Id: Ic1edc623dff568d54d3ce29b42dd8eab3312f5cb
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342225
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Sergey Silkin <ssilkin@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41986}
This is a reland of commit 7ae48c452abf8694a1b0a7a9a2aef13a9d10298a with updated RtpVp9RefFinder
RtpVp9RefFinder relied on the fact that frames with (inter_pic_predicted=true && inter_layer_predicted=true) were marked as keyframes. Since this is not the case anymore, the related code paths in RtpVp9RefFinder have been deleted.
Calculation of gof_info_[] index for non-keyframes has been updated to account for that fact it is now possible to received multiple T0 frames belonging to the same temporal unit (we don't need to do "unwrapped_tl0 - 1" in this case).
Original change's description:
> Mark frames with inter_layer_predicted=true as delta frames
>
> As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
>
> Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
>
> This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
>
> When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
>
> [2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
>
> Bug: webrtc:15827
> Change-Id: Idc3445636f0eae0192dac998876fedec48628560
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41939}
Bug: webrtc:15827
Change-Id: Ic69b94989919cf6d353bceea85d0eba63bc500ee
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344144
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41985}
This is a follow-up to:
https://webrtc-review.googlesource.com/c/src/+/318640
The problem was that the scoped field trials in the tests only
applied to the construction of the streams, not the handshake.
Note, although the changes are in OpenSSLStreamAdapter, this CL
actually fixes the SSLStreamAdapterTestDTLSExtensionPermutation tests
in rtc_base/ssl_stream_adapter_unittest.cc.
Bug: webrtc:15467
Change-Id: I25cdd758aab1bc67fd7a6a61c956c6d52f82e3d1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344762
Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41976}
With this cl
RtpTransportControllerSend::OnAddPacket is instead directly invoked from PacketRouter::SendPacket instead of going via RTP module.
Transport sequence numbers are instead of directly written to header
extension, added to RtpPacketToSendMetaData and written to the extenion
by RTP module.
This is to allow transport sequence numbers without actually sending
them in an extension.
Bug: webrtc:15368
Change-Id: Idd03e02a4257dfc4d0f1898b2803345975d7dad2
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344720
Reviewed-by: Erik Språng <sprang@google.com>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41974}
This reverts commit d427e83a15ad2950095ce1d352cc7e11eaf6cad3.
Reason for revert: Flaky test fixed.
Refactor FrameCandenceAdapter to keep track of input frame rate. This fixes an issue where frame rate is calculated too low if congestion window drop a frame.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887, webrtc:15893
Change-Id: I76268aa0991dbc99c1b881fb251a76aa54ff2673
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344561
Reviewed-by: Erik Språng <sprang@google.com>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41972}
The timeout was not long enough in debug mode on slower machines.
Bug: chromium:40072842
Change-Id: Id82399cd7211abf5dd2e03ffa2ee4bd49f8c492f
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344680
Commit-Queue: Florent Castelli <orphis@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41971}
This reverts commit 784af1f42e89735587c442855fa01fc90475c449.
Reason for revert: Seems like test test_support_unittests
ResolutionAdaptsToAvailableBandwidth is flaky with this cl.
Original change's description:
> FrameCadenceAdapter keep track of Input framerate
>
> Refactor FrameCandenceAdapter to keep track of input frame rate.
>
> Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
> Uma is recorded to tell if input frame timestamp is monotonically increasing.
>
> Bug: webrtc:10481, webrtc:15887
> Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41967}
Bug: webrtc:10481, webrtc:15887
Change-Id: Id9672764768f2f40f8e711e990ad8ac18c28efcc
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344560
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41969}
Refactor FrameCandenceAdapter to keep track of input frame rate.
Also a field trial WebRTC-FrameCadenceAdapter-UseVideoFrameTimestamp is added to control if VideoFrame timestamp should be used or local clock when calculating frame rate.
Uma is recorded to tell if input frame timestamp is monotonically increasing.
Bug: webrtc:10481, webrtc:15887
Change-Id: I6d698e9f9dcfe8c023d2d35371435c47f70102b0
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342760
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41967}
This reverts commit 802dd5bdbd97d880761059c7362c9e843211e32d.
First patch set is pure reland.
New patch set adds field trial flag.
Original change's description:
Stop exponential probing if 2xmax allocated bitrate lower than BWE.
Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
Bug: webrtc:14928
Change-Id: I35c341bbaced800d9931657d62c73a17a3279b7c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344440
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Reviewed-by: Diep Bui <diepbp@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41965}
When refactoring the WGC capture path, the check of a closed source
had been placed at a level where the notification of a closed source
was left without being detected since the error message was never
provided to the main WgcCapturerWin::CaptureFrame() which sends the
error message up to the client.
This trivial change ensures that WgcCapturerWin::CaptureFrame() returns
with DesktopCapturer::Result::ERROR_PERMANENT as soon as
WgcCaptureSession::OnItemClosed() has been triggered and it will
ensure that the WGC capture session stops and that any attached
MediaStreamTrack will signal its onended event as expected.
Bug: chromium:330863510
Change-Id: I57e44df417c33efa0595fc277cac5429cf539b26
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344420
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Henrik Andreassson <henrika@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41963}
After we're done sending all the messages, if the channel was in closing
state, then we start closing the association at the SCTP level, which
allows transitioning to the closed state.
Bug: chromium:40072842
Change-Id: I81b26b4137593b8feeb4bd9a2563cdfd67e1049e
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344421
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Victor Boivie <boivie@webrtc.org>
Auto-Submit: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41962}
The purpose is to be able to create a RtpPacketSendInfo from Pacing and RtpPacketSendInfo only.
This allow further refactoring where we directly in PacketRouter can notify BWE and early loss detection that a packet will be sent.
RtpPacketSendInfo::From is mostly added to be able to test conversion.
Bug: webrtc:15368
Change-Id: I5ebe2dc91d2eedf2c86e62c3f9738437082a49e4
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343766
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41961}
This reverts commit 5a4ce031019bce349ad65e76aa5da6d0f8e5989e.
Reason for revert: Breaks tests in downstream project.
Original change's description:
> Stop exponential probing if 2xmax allocated bitrate lower than BWE.
>
> Without this, if max allocated bitrate is lowered while exponential probing is ongoing, a new probe can be sent at a rate of the new low max allocated bitrate which may cause BWE to decrease.
>
> Bug: webrtc:14928
> Change-Id: Id8e314740c2403d3b801d28f634dbc718f77c16e
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343384
> Reviewed-by: Diep Bui <diepbp@webrtc.org>
> Commit-Queue: Per Kjellander <perkj@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41929}
Bug: webrtc:14928
Change-Id: I0d48b37bfb8684fd490f5685e510b438a83254b9
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343900
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Ying Wang <yinwa@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41958}
This field trial will be used to roll out support for message
interleaving (RFC8260).
Bug: webrtc:5696
Change-Id: I5f91e8910ca5949fd62362a01e66f1e9bf834f81
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343765
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41955}
This reverts commit 7ae48c452abf8694a1b0a7a9a2aef13a9d10298a.
Reason for revert: breaks RtpVp9RefFinder
Original change's description:
> Mark frames with inter_layer_predicted=true as delta frames
>
> As it is currently implemented, the VP9 depacketizer decides packet's frame type based on p_bit ("Inter-picture predicted layer frame"). p_bit is set to 0 for upper spatial layer frames of keyframe since they do not have temporal refs. This results in marking packets of upper spatial layer frames, and, eventually these frames, of SVC keyframes as "keyframe" while they are in fact delta frames.
>
> Normally spatial layer frames are merged into a superframe and the superframe is passed to decoder. But passing individual layers to a single decoder instance is a valid scenario too and is used in downstream projects. In this case, an upper layer frame marked as keyframe may cause decoder reset [2] and break decoding.
>
> This CL changes frame type decision logic in the VP9 depacketizer such that only packets with both P and D (inter-layer predicted) bits unset are considered as keyframe packets.
>
> When spatial layer frames are merged into a superframe in CombineAndDeleteFrames [1], frame type of the superframe is inferred from the lowest spatial layer frame.
>
> [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/modules/video_coding/frame_helpers.cc;l=53
>
> [2] https://source.corp.google.com/piper///depot/google3/third_party/webrtc/files/stable/webrtc/modules/video_coding/codecs/vp9/libvpx_vp9_decoder.cc;l=209
>
> Bug: webrtc:15827
> Change-Id: Idc3445636f0eae0192dac998876fedec48628560
> Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343342
> Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
> Cr-Commit-Position: refs/heads/main@{#41939}
Bug: webrtc:15827
Change-Id: I697a057b8b3e88c07499f77c42f014da43cf1dc1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343763
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Sergey Silkin <ssilkin@webrtc.org>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#41953}
After cl https://webrtc-review.googlesource.com/c/src/+/343122 there is
no default max frame rate.
Bug: webrtc:15885
Change-Id: Iac38895486d31bd267b578bbd1ab905dcdae00ff
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344142
Reviewed-by: Jeremy Leconte <jleconte@google.com>
Commit-Queue: Erik Språng <sprang@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Auto-Submit: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41952}
The purpose of these new methods are to allow creating a RTP packet with
sequence numbers that
can be inspected and is ensured to be sent if SendPacket is invoked.
virtual bool CanSendPacket(const RtpPacketToSend& packet) const = 0;
virtual void AssignSequenceNumber(RtpPacketToSend& packet) = 0;
virtual void SendPacket(std::unique_ptr<RtpPacketToSend> packet,
const PacedPacketInfo& pacing_info) = 0;
Bug: webrtc:15368
Change-Id: I671e737575e15328e796aa98761a4d540c5812d6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343785
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Per Kjellander <perkj@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#41951}
