The desktop capturer uses a circular queue (currently of length 2) to
implement a double-buffer scheme. This allows a C++ API consumer to keep
a reference to the latest captured image without the pixels being
overwritten by a pending capture request.
The DCHECK was intended to warn that the application is still holding a
reference to a recycled frame that is being captured into. This made
sense when the capturer implementations were originally part of the
Chromoting host process. Now that the capturers are part of the WebRTC
C++ library, a DCHECK seems too harsh. A DCHECK should be reserved for
impossible conditions, but this one triggers simply because an API
consumer holds onto a reference for too long. This CL changes these
DCHECKs into log warnings.
The DCHECK is sometimes triggered by the Chromoting host process
(because of the recent change to use the standard encoding pipeline).
This is tracked by http://crbug.com/1239746.
Bug: None
Change-Id: Iad9ef38b4800315bd17c93b27d287e115d4fe54c
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/230881
Commit-Queue: Joe Downing <joedow@chromium.org>
Reviewed-by: Joe Downing <joedow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#34910}
7add207ada