Skip to content

VIDECO - 11521#916

Open
Mike-Zhylevych wants to merge 35 commits intodevelopfrom
VIDECO-11521
Open

VIDECO - 11521#916
Mike-Zhylevych wants to merge 35 commits intodevelopfrom
VIDECO-11521

Conversation

@Mike-Zhylevych
Copy link
Contributor

@Mike-Zhylevych Mike-Zhylevych commented Jan 30, 2026

This pull request introduces a new OpenTok video renderer to enable accurate screen sharing overlays by capturing subscriber video frames as Bitmaps. It also adds infrastructure to manage screen capturers per session and wires up subscriber overlays so their video can be composited into screen capture streams. The most important changes are grouped below:

Screen Capture Infrastructure:

  • Added a screenCapturers map to the OTRN singleton, with a getter for accessing all active OTScreenCapturer instances by session ID. [1] [2]
  • In OTRNPublisher, when using the "screen" video source, an OTScreenCapturer is created, stored in the shared state, and cleaned up on view detachment. [1] [2] [3]

Subscriber Video Frame Capture and Overlay:

  • Introduced OTCaptureBmpVideoRenderer, a custom OpenTok renderer that displays subscriber video in a GLSurfaceView and captures each frame as a Bitmap for overlay during screen sharing.
  • Updated OTRNSubscriber to use OTCaptureBmpVideoRenderer for each subscriber, wiring its onBitmapFrame callback to update the corresponding OTScreenCapturer with the latest video frame Bitmap.

Overlay Wiring and Lifecycle:

  • Added logic in OTRNSubscriber to wire up subscriber overlays to the appropriate OTScreenCapturer whenever a subscriber view is created or when the subscriber is connected. [1] [2] [3]

Feature screenshots are attached

Screenshot 2026-01-30 at 15 07 31 Screenshot 2026-01-30 at 15 13 11

@joliveraortega joliveraortega changed the base branch from release-2.31.1 to develop February 3, 2026 16:19
// Clean up screen capturer if any
OTScreenCapturer sc = sharedState.getScreenCapturers().remove(sessionId);
if (sc != null) {
try { sc.stopCapture(); } catch (Throwable ignored) {}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if this fails? Can we just put both stopCapture and destroy in the same try/catch?
Maybe we should log something in the catch at least?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it makes sense, thank you @igorperunovicvonage. I have combined both method invocations into a single try/catch block. Regarding Logging, I'm not sure we need it here since this is just a guard, and even if it fails JAVAs garbage collector should remove it from memory anyway.

@Mike-Zhylevych Mike-Zhylevych requested a review from a team as a code owner February 17, 2026 15:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

Comments