Artem Titarenko 658dfb74e5 RTP video stream receivers: By default consider frames decryptable.
Looks like the original code [0] that should limit the amount of keyframe requests behaves a bit strange in a situation when the first keyframe is missed. Effectively in the encrypted session the receiver can't enforce getting the keyframe until it receives at least one frame which is decryptable [1]. And with dependency descriptors it can't do that until it receives a keyframe which contains proper DD header [2]. This leads to unnecessary delays until the sender sends a keyframe itself.

In this CL we "trust" that the stream is decryptable from the beginning unless proven the opposite [3].

[0]: https://webrtc-review.googlesource.com/c/src/+/123414/
[1]: https://webrtc.googlesource.com/src/+/9432768024b0397f2dccfec0cab30f33dde87b93/video/video_receive_stream2.cc#950
[2]: https://webrtc.googlesource.com/src/+/9432768024b0397f2dccfec0cab30f33dde87b93/video/rtp_video_stream_receiver2.cc#415
[3]: https://webrtc.googlesource.com/src/+/9432768024b0397f2dccfec0cab30f33dde87b93/video/rtp_video_stream_receiver2.cc#882

Bug: webrtc:10330
Change-Id: I167d728ddc7cde74a5c5e3327bce7364ed97b7ea
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/260326
Reviewed-by: Philip Eliasson <philipel@webrtc.org>
Reviewed-by: Erik Språng <sprang@webrtc.org>
Commit-Queue: Artem Titarenko <artit@webrtc.org>
Cr-Commit-Position: refs/heads/main@{#36775}
2022-05-05 09:58:28 +00:00
..
2022-05-05 09:43:31 +00:00