How to record Picture-in-Picture windows

Recording a window is straightforward until the content you care about moves somewhere else. Picture-in-Picture is one of the clearest examples: the recording session continues, but the capture target may change.

What is Picture-in-Picture?

Picture-in-Picture, or PiP, moves video out of its original application or browser surface and into a small floating window.

People use PiP to keep content visible while doing something else, including:

• watching video while browsing
• staying in a meeting while working in another tab
• following training content while using another application

For recording software, PiP matters because the content you were capturing can move to a new window.

Before Picture-in-Picture is enabled, the video is part of the original browser or application window.

Once Picture-in-Picture is enabled, that video may move into a separate floating window. The original window can then show something else.

If your recorder keeps capturing only the original window, it may lose the video or record unrelated content instead.

That is why PiP should be treated as a source-switching problem.

Why PiP creates a new recording target

What happens next depends on what your product records.

A recorder capturing an entire display may already include PiP because the floating window is visible on that display.

A window recorder may need to detect and capture the PiP window separately.

A session recorder may need to treat PiP as the new visual representation of the same session.

Take a meeting recorder. If a user moves away from the meeting while a PiP window continues showing it, the relevant capture target may have changed even though the meeting itself has not.

The same applies to detached video playback. If the product is meant to record the video rather than the browser, it should follow the video into PiP.

Detecting a Picture-in-Picture window

Depending on the operating system, useful signals for identifying a PiP window can include:

• owning process
• window title
• window bounds
• window ID
• whether the window is onscreen
• browser or application metadata

On macOS, for example, ScreenCaptureKit exposes capturable windows through SCShareableContent. An SCWindow can provide information such as its window ID, title, owning application, frame, layer, and onscreen state.

But the operating system does not simply tell you which window maps to the session you’re recording.

You still need to correlate the new window with the existing session.

That matters because a user may have multiple videos or floating windows open. Choosing the newest or smallest window is not enough.

How to record the PiP window

Once you identify the correct surface, the basic flow is:

1. Detect the new window - Find the newly available capture surface.

2. Verify it - Confirm that it belongs to the video, meeting, or session you are recording.

3. Start capturing it - On macOS, for example, ScreenCaptureKit can create a content filter for a specific SCWindow and use it as the source for an SCStream.

4. Confirm that frames are arriving - Do not assume a capture is ready just because the window exists.

5. Switch away from the previous source - Stop using the old visual source once the PiP capture is usable.

6. Keep the same session timeline - The capture surface changed. The recording session did not.

Even though the capture surface changes when transitioning to a PiP, the recording session does not. Keep the new video source on the same timeline so it stays synchronized with the existing audio and any other session data.

Switching capture sources without losing content

Switching from the original window to a PiP window is often harder than capturing either one on its own.

The main problem is timing. If you stop capturing the original surface before the PiP window is ready, you can create a gap in the recording. If you keep capturing the original surface for too long, you may briefly record whatever unrelated content replaced the video.

The transition can also produce dropped or duplicate frames, black frames, interrupted capture streams, or recording segments that do not finalize correctly.

A safer approach is to start capturing the new PiP surface before retiring the old one. Confirm that the new stream is producing valid frames, record when the handoff occurred, and then stop and finalize the previous capture.

Source switching should not be treated as an instantaneous change. Capture streams take time to start, produce usable frames, and shut down cleanly, so the handoff needs to account for that lifecycle.

A recorder built from scratch for Google Meet ran into these problems when switching between the main meeting view and its PiP surface, including fragmented files and dropped frames during transitions.

Keep audio independent from the video source

Changing the window you capture does not necessarily mean you should change how you capture audio.

This is especially important for meetings. A user might start in the main meeting window, move the meeting into PiP while they work elsewhere, and later return to the full meeting view. The video source changes during that time, but the meeting audio can continue uninterrupted.

Keeping audio capture independent from these video transitions means you do not have to restart it every time PiP appears or disappears. Instead, the different video segments can remain aligned to the same session timeline as the continuous audio.

This reduces the risk of audio gaps or synchronization problems and helps preserve a continuous transcript even as the visual capture source changes.

What happens when PiP closes?

Entering PiP and leaving it are separate transitions, and can fail in different ways.

A PiP window may disappear because the user returns to the original content, playback ends, the user closes PiP, or the application changes state. When that happens, the recorder has to decide what should become the next capture source. Depending on the product, that might mean returning to the original window, finding another valid surface, continuing without video, or stopping the recording.

Do not assume that switching into PiP successfully means switching back will work the same way. A tutorial built using Google Meet found different failures when leaving the miniplayer, including cases where capture ended before the PiP segment had been finalized correctly.

Treat entering and leaving PiP as separate states and test both independently.

Stitching recordings across PiP transitions

Some capture architectures create a new physical recording segment each time the video source changes. A session that starts in the main window, moves into PiP, and later returns to the main window might therefore produce three separate video files.

From the user's perspective, however, those files are still part of one recording.

Keep a session-level timeline that records when each segment starts and ends, then use those timestamps to combine the segments after capture. During that process, check that audio and video remain aligned and that the transition has not introduced missing frames, duplicate frames, timestamp gaps, or visible artifacts.

Each segment also needs to be finalized correctly. If a PiP window disappears unexpectedly, capture may stop before the media container has been cleanly closed, which can leave the segment incomplete or unusable.

The Google Meet recorder case study ultimately handled this by treating each capture period as a separate segment and merging them into one recording afterward.

PiP recording outside of meetings

The same approach applies outside meeting software.

A video recorder may need to keep following detached playback while the user browses elsewhere. A training product may need to keep recording instructional video in PiP while the user works in another application. A remote-support tool may need to preserve a support-video surface while the user troubleshoots another app. A workflow recorder may simply treat PiP as one of several capture surfaces that can appear and disappear during a session.

In each case, the recorder needs to identify the relevant PiP surface, confirm that it belongs to the session being recorded, switch capture safely, and keep the new source on the same session timeline.

What changes between products is how the product decides which surface belongs to the recording.

Why meeting recording makes PiP harder

Meetings add several moving parts at once.

The UI can change as participants join, speakers change, or screen sharing starts. PiP may show a different layout from the full meeting window. Browser and meeting-platform behavior can also differ.

At the same time, the recorder may need to preserve:

• meeting audio
• speaker context
• screen-share state
• transcription timing
• session metadata

That means PiP is only one state inside a larger meeting-recording system.

This is also why PiP and multitasking are closely related. A meeting recorder should continue following the meeting when the user's attention moves elsewhere; PiP is one way a meeting surface can remain available during that transition.

Handling PiP with a desktop recording SDK

If your product depends on reliably recording meetings, PiP handling is usually infrastructure rather than something you should build from scratch. A desktop SDK will eliminate the maintenance you’ll need to do and will allow you to record the target as meeting surfaces appear, disappear, or change, while keeping audio, video, and session state continuous.

Depending on the SDK, that can include identifying the relevant meeting surface, responding to PiP and other window changes, switching capture targets, and keeping those transitions within one logical recording session.

That lets your team focus on the parts of the product that are actually specific to your users, such as workflows, collaboration, search, summaries, integrations, or application UX.

There are still platform constraints. A PiP view can expose a different layout or lower-quality video than the full meeting window, and operating systems or meeting platforms may limit what can be captured in certain states.

If you do implement PiP handling yourself, you need to identify the new surface, verify that it belongs to the current session, start and validate capture, transition away from the previous source, preserve the session timeline, and handle the transition back when PiP closes.

By offloading the recording to a desktop SDK, you can eliminate the time, money, engineering resources, and stress spent on recording and build the parts of the product that your users interact with or that are proprietary to your company.