The latter is also a member of the former. This cleanup is also
a preparation for dropping WebRtcRTPHeader::frameType (or deleting
WebRtcRTPHeader right away), now that it's a video-specific member.
Tbr: kwiberg@webrtc.org # Comment change in modules/include/
Bug: None
Change-Id: I5c1f3f981f0d750713fc9b9b145278150fe32b5d
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/133024
Commit-Queue: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27740}
This change refactors the FrameDecryptorInterface to use the new API. The new
API surface simply moves bytes_written to the return type and implements a
simple Status type.
Bug: webrtc:10512
Change-Id: I622c5d344d58e618853c94c2f691cf7c8fb73a36
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/131460
Reviewed-by: Steve Anton <steveanton@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27497}
This change introduces new logic to allow the injection of the FrameDecryptor
into an arbitrary already running VideoReceiveStream without resetting it. It
does this by taking advantage of the BufferedFrameDecryptor which will
forcefully be created regardless of whether a FrameDecryptor is passed in
during construction of the VideoReceiver if the
crypto_option.require_frame_encryption is true. By allowing the
BufferedFrameDecryptor to swap out which FrameDecryptor it uses this allows the
Receiver to switch decryptors without resetting the stream.
This is intended to mostly be used when you set your FrameDecryptor at a point
post creation for the first time.
Bug: webrtc:10416
Change-Id: If656b2acc447e2e77537cfa394729e5c3a8b660a
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/130361
Commit-Queue: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Jonas Oreland <jonaso@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27458}
VCMReceiveStatisticsCallback originates in the old jitter buffer, and
is no longer used.
VCMFrameTypeCallback originates in VideoReceiver::RequestKeyFrame,
which is called from OncomingPacket, Process, Decode(uint16_t
maxWaitTimeMs), all of which are unused by VideoReceiveStream.
So delete the code to wire them up via VideoStreamDecoder.
Bug: webrtc:7408
Change-Id: I173bc94eb32f2641f943c125083db038c3bcaeb1
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/128870
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#27277}
The current Key Frame request system doesn't take into account failed
decryptions and this can lead to WebRTC spamming new key frame requests when
the issue is actually in the decryptor layer. To prevent this if frame
decryption is required for the PeerConnection key frame requests will not be
sent at 200ms intervals but will wait until the stream is decryptable before
utilizing this logic.
Bug: webrtc:10330
Change-Id: I188a21dfd142dec6175d9def95f39a2bc517017c
Reviewed-on: https://webrtc-review.googlesource.com/c/123414
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26931}
* LossNotificationController is the class that decides when to issue
LossNotification RTCP messages.
* RtpRtcp handles the technicalities of producing RTCP messages.
Bug: webrtc:10336
Change-Id: I292536257a984ca85d21d9cfa38e7ff2569cbb39
Reviewed-on: https://webrtc-review.googlesource.com/c/124123
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Elad Alon <eladalon@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26840}
This change introduces a new class BufferedFrameDecryptor that is responsible
for decrypting received encrypted frames and passing them on to the
RtpReferenceFinder. This decoupling refactoring was triggered by a new
optimization also introduced in this patch to stash a small number of
undecryptable frames if no frames have ever been decrypted. The goal of this
optimization is to prevent re-fectching of key frames on low bandwidth networks
simply because the key to decrypt them had not arrived yet.
The optimization will stash 24 frames (about 1 second of video) in a ring buffer
and will attempt to re-decrypt previously received frames on the first valid
decryption. This allows the decoder to receive the key frame without having
to request due to short key delivery latencies. In testing this is actually hit
quite often and saves an entire RTT which can be up to 200ms on a bad network.
As the scope of frame encryption increases in WebRTC and has more specialized
optimizations that do not apply to the general flow it makes sense to move it
to a more explicit bump in the stack protocol that is decoupled from the WebRTC
main flow, similar to how SRTP is utilized with srtp_protect and srtp_unprotect.
One advantage of this approach is the BufferedFrameDecryptor isn't even
constructed if FrameEncryption is not in use.
I have decided against merging the RtpReferenceFinder and EncryptedFrame stash
because it introduced a lot of complexity around the mixed scenario where some
of the frames in the stash are encrypted and others are not. In this case we
would need to mark certain frames as decrypted which appeared to introduce more
complexity than this simple decoupling.
Bug: webrtc:10022
Change-Id: Iab74f7b7d25ef1cdd15c4a76b5daae1cfa24932c
Reviewed-on: https://webrtc-review.googlesource.com/c/112221
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25865}
When FlexFEC is enabled, sometimes media packet will be recovered by FEC before the actual media packet's arrival. In current implementation this will be considered as packet out of order and nack will be sent, thus cause large increase in retransmit bitrate.
This fix:
1. Avoid sending nack for packet out of order caused by "early" recovered media packets.
2. Save recovered media packet in a set, and do not send nack for these packets.
Bug: None
Change-Id: I008ef4e33668bce6d2cb9ff52b4b5c8e3f349965
Reviewed-on: https://webrtc-review.googlesource.com/c/108090
Commit-Queue: Ying Wang <yinwa@webrtc.org>
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25444}
This change enables the FrameDecryptor attached to an RtpVideoReceiver to do
an initial request for a KeyFrame if the first successfully decrypted payload
is not a key frame.
Bug: webrtc:9795
Change-Id: I401ce1f513cb51ce520b60dcaf8b825a68d00c7f
Reviewed-on: https://webrtc-review.googlesource.com/c/107246
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25295}
This change integrates the FrameDecryptorInterface and the FrameEncryptorInterface into
the video send and receive path. If a FrameEncryptorInterface is set on an outgoing video RTPSender
then each outgoing video frame will first pass through the provided FrameEncryptor which
will have a chance to modify the payload contents for the purposes of encryption. In addition to
this the new GenericFrameDescriptor will be added as additional data.
If a FrameDecryptorInterface is set on an incoming video RtpReceiver then each incoming
video payload will first pass through the provided FrameDecryptor which have a chance to
modify the payload contents for the purpose of decryption.
Bug: webrtc:9795
Change-Id: I9f743ce0cb63df0cf070f6144be7ada078b4e5d2
Reviewed-on: https://webrtc-review.googlesource.com/c/103920
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Commit-Queue: Benjamin Wright <benwright@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#25258}
And also drop dependency on module_api, where possible. With this
change, common_video/ no longer depends on
libjingle_peerconnection_api.
Bug: None
Change-Id: Icc0648559bef5b7f549e81d58f2a5f97c0af3abf
Reviewed-on: https://webrtc-review.googlesource.com/c/103782
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24991}
This CL makes the RtpGenericFrameDescriptor available in
RTPSenderVideo::SendVideo for encryption and in
RtpVideoStreamReceiver::OnReceivedFrame for decryption.
Bug: webrtc:9361
Change-Id: I5b6d10138c0874657862f103c8c9a2328e6d4a66
Reviewed-on: https://webrtc-review.googlesource.com/102720
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24929}
Add new method OnRtpPacket, but leave
ReceiveStatisticsImpl::IncomingPacket and most of the implementation
unchanged. Deleting the old method and converting implementation from
RTPHeader to RtpPacketreceived is planned for a followup, after
downstream code is updated.
Bug: webrtc:7135, webrtc:8016
Change-Id: I697ec12804618859f8d69415622d1b957e1d0847
Reviewed-on: https://webrtc-review.googlesource.com/100104
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Stefan Holmer <stefan@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24889}
Return value always passed as the |retransmitted| argument to
ReceiveStatistics::IncomingPacket. The implementation of this method,
StreamStatisticianImpl::IncomingPacket, can call its own
IsRetransmitOfOldPacket, which is demoted to a private method.
Bug: webrtc:7135
Change-Id: I904db676738689c7a1db4caa588f70e64e3c357d
Reviewed-on: https://webrtc-review.googlesource.com/95649
Reviewed-by: Åsa Persson <asapersson@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24494}
This CL removes //build/config/clang:find_bad_constructs from the
suppressed_configs list, which means that clang:find_bad_constructs
is now enabled on these translation units.
Bug: webrtc:9251, webrtc:163
Change-Id: I74cb86c29cebb69dd22083718f1446f18f705cd4
Reviewed-on: https://webrtc-review.googlesource.com/95883
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#24483}
this function is now only used in combination with StreamStatistician::IsRetransmitOfOldPacket
but IsRetransmitOfOldPacket internally checks if packet is in_order, thus making extra check unnecessary
In addition to making code simpler, removing this checks avoids
taking two extra CritSection on common code path of incoming rtp packet.
Bug: webrtc:8016
Change-Id: I050004e256b5698ce700e3416aa86b55f446a270
Reviewed-on: https://webrtc-review.googlesource.com/85361
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Fredrik Solenberg <solenberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23762}
This is a no-op change because rtc::Optional is an alias to absl::optional
This CL generated by running script with parameters 'audio call video':
#!/bin/bash
find $@ -type f \( -name \*.h -o -name \*.cc \) \
-exec sed -i 's|rtc::Optional|absl::optional|g' {} \+ \
-exec sed -i 's|rtc::nullopt|absl::nullopt|g' {} \+ \
-exec sed -i 's|#include "api/optional.h"|#include "absl/types/optional.h"|' {} \+
find $@ -type f -name BUILD.gn \
-exec sed -r -i 's|"(../)*api:optional"|"//third_party/abseil-cpp/absl/types:optional"|' {} \+;
git cl format
Bug: webrtc:9078
Change-Id: I02c5db956846a88a268a300ba086703a02d62e36
Reviewed-on: https://webrtc-review.googlesource.com/83722
Reviewed-by: Karl Wiberg <kwiberg@webrtc.org>
Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23628}
This is a reland of 3409cfa378e75c0c08d900e0848147929249a62b
Needed to change RtpVideoStreamReceiver to stop deregistering a payload
type if two payload types refer to the same codec (which now happens,
with the packetization mode 0/1 payload types). It's not clear why this
was being done in the first place.
Original change's description:
> Start supporting H264 packetization mode 0.
>
> The work was already done to support it, but it wasn't being negotiated
> in SDP.
>
> This means we'll now see 8 H264 payload types instead of 4; one for each
> combination of BP/CBP profiles, packetization modes 0/1, and RTX/non-RTX.
> This could be problematic in the future, since we're starting to run
> out of dynamic payload types (using 25 of 32).
>
> Bug: chromium:600254
> Change-Id: Ief2340db77c796f12980445b547b87e939170fae
> Reviewed-on: https://webrtc-review.googlesource.com/77264
> Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
> Reviewed-by: Erik Språng <sprang@webrtc.org>
> Reviewed-by: Magnus Jedvert <magjed@webrtc.org>
> Cr-Commit-Position: refs/heads/master@{#23372}
Bug: chromium:600254
Change-Id: Ice1acc05acd1543d9b46e918de2bba0694d86259
Reviewed-on: https://webrtc-review.googlesource.com/78399
Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Commit-Queue: Taylor Brandstetter <deadbeef@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#23494}
Both of these implementations are added as observers by
VideoReceiveStream, which is also an observer.
Instead, VideoReceiveStream now forward the necessary information
when the stats are updated as is already done for |frame_buffer_|.
Fewer observers registered, simplifies the code a little bit,
reduces synchronization when registering/unregistering observers
and reduces the set of existing implementations.
(I'm changing call_stats.* a little bit, so this is a by-the-way change)
Bug: none
Change-Id: I2d40b80a60e5ca632293c5118ac3b1a35d48ea40
Reviewed-on: https://webrtc-review.googlesource.com/64524
Reviewed-by: Magnus Flodman <mflodman@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22594}
This also has the benefit of deleting one unneeded call to
RTPPayloadRegistry::last_received_media_payload_type.
To make this work, also extend NackModule with a OnReceivedPacket
method taking only the sequence number and the is_keyframe flag,
rather than a complete VCMPacket.
Bug: webrtc:8995
Change-Id: Ice379581166e7b1609ec719e944a5a543d69acc1
Reviewed-on: https://webrtc-review.googlesource.com/64120
Reviewed-by: Erik Språng <sprang@webrtc.org>
Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
Commit-Queue: Niels Moller <nisse@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22584}
The plan is to:
1. Move FrameObject to api/video.
2. Rename FrameObject to EncodedFrame.
3. Move EncodedFrame out of the video_coding namespace.
This is the 2nd CL.
Bug: webrtc:8909
Change-Id: I5e76a0a3b306156b8bc1de67834b4adf14bebef9
Reviewed-on: https://webrtc-review.googlesource.com/56182
Commit-Queue: Philip Eliasson <philipel@webrtc.org>
Commit-Queue: Tommi <tommi@webrtc.org>
Reviewed-by: Niels Moller <nisse@webrtc.org>
Reviewed-by: Tommi <tommi@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#22158}
