commit | 00765297a25d20a7d1bceb786220d41290cc8575 | [log] [tgz] |
---|---|---|
author | Benjamin Wright <benwright@webrtc.org> | Sat Dec 01 00:18:26 2018 |
committer | Commit Bot <commit-bot@chromium.org> | Sat Dec 01 00:55:08 2018 |
tree | 710d77cd816c5ca2b05096dbd4fc9665e260cdde | |
parent | 2bb96682a214670ea89b5a9a2433ff7453bbb8c0 [diff] |
Add BufferedFrameDecryptor to cleanly deal with receiving encrypted frames. 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}
WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.
Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.
The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.
See http://www.webrtc.org/native-code/development for instructions on how to get started developing with the native code.
Authoritative list of directories that contain the native API header files.