> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stmlink.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> 对外开放的服务端接口有两组前缀，都用同一套鉴权：`/server/v1/...`（SRTC 与 SMeeting 的主接口）和 `/stm/srvapi/v1/...`（SMeeting 的用户体系，服务端极简对接会用到）。鉴权是 app_id + nonce + timestamp + signature 四个请求头，用 app_key 做 HMAC-SHA256 签名，只能从业务方自己的后端调用。除这两组前缀外的接口均为内部接口，不要建议客户调用。 Public server APIs use two path prefixes with the same authentication: `/server/v1/...` (the main APIs of both SRTC and SMeeting) and `/stm/srvapi/v1/...` (the SMeeting user system, used by server-side low-code integration). Authenticate with four request headers, app_id + nonce + timestamp + signature, where signature is HMAC-SHA256 keyed with app_key; call these APIs only from the customer's own backend. Any other path is internal: never suggest calling it.
> app_key 是服务端密钥，绝不能出现在客户端代码、前端配置或移动 App 里。客户端加入频道用的 token 必须由业务方后端签发后下发（SRTC 走 `/server/v1/channel/grant`，SMeeting 走 `/stm/srvapi/v1/member/grant`）。 app_key is a server-side secret and must never appear in client code, frontend config, or a mobile app. The token a client uses to join must be issued by the customer's backend and passed down to the client (SRTC: `/server/v1/channel/grant`; SMeeting: `/stm/srvapi/v1/member/grant`).
> SRTC 与 SMeeting 是上下两层不同的产品，术语不通用：SRTC 是音视频底座，说「频道 channel」「加入 / 退出」；SMeeting 建在 SRTC 之上，说「房间 room」「会议 meeting」「进入 / 退出」。回答时按用户所在的层用对应术语，不要把「房间」「会议」安到 SRTC 的接口上，也不要用「频道」「加入 / 离开」描述 SMeeting 的概念（接口标识符原样保留）。 SRTC and SMeeting are two separate layers with different terminology. SRTC is the audio/video foundation: it has channels, and users join and leave a channel. SMeeting is built on top of SRTC: it has rooms and meetings, and members enter and exit a meeting. Answer in the terms of the layer the user is working with: never apply "room" or "meeting" to SRTC APIs, and never describe SMeeting concepts in prose with "channel", "join", or "leave" (API identifiers such as `force_join` keep their literal names).
> 同一能力在各端 SDK 里的包名、类名、方法名并不相同。写示例代码时请使用文档中该端自己的 API，不要把一个端的写法套到另一个端上。苹果平台每个产品都有两套 SDK（Swift 原生与 Objective-C），两套 API 不能混用。 Package, class, and method names differ between platform SDKs for the same capability. In sample code, use the API documented for that platform; never carry one platform's code over to another. On Apple platforms each product ships two SDKs (native Swift and Objective-C) whose APIs must not be mixed.

# Multi-window and dual-screen video layout

> Show video in separate windows with the Web SDK: pop out a track to its own window for dual-screen layouts, keep a floating camera window via picture-in-picture while sharing the screen, sync UI with TRACK_PIP_* / TRACK_POPOUT_* events, and clean up when sharing ends.

When your app needs to put video in a separate window or on a second monitor, or keep a small window of your own camera while sharing the screen, you can combine the following capabilities:

* `enterPictureInPicture(container, options?)`
* `popOutToWindow(container, options?)`
* `closePopOutWindow(container)`
* `ChannelEventType.TRACK_PIP_ENTER / TRACK_PIP_EXIT`
* `ChannelEventType.TRACK_POPOUT_OPEN / TRACK_POPOUT_CLOSE`

***

### Scenario 1: dual-screen layout

Typical requirements:

* Monitor A shows the remote shared desktop
* Monitor B shows the local camera or a remote person's video

The recommended approach:

* Keep using `addPlayView(container)` on the main page to maintain the video card structure
* When the user clicks "Pop out", call `popOutToWindow`
* Drag the new window popped out by the browser to the second monitor

```typescript theme={null}
const remoteScreenTrack = await srtc.subscribeRemoteVideoTrack(uid, trackId);
remoteScreenTrack.addPlayView(document.querySelector('#remote-screen')!);

remoteScreenTrack.popOutToWindow(
  document.querySelector('#remote-screen')!,
  {
    title: 'Remote shared desktop',
    width: 1600,
    height: 900,
    hideOriginView: true,
  }
);

localCameraTrack.addPlayView(document.querySelector('#local-camera')!);
localCameraTrack.popOutToWindow(
  document.querySelector('#local-camera')!,
  {
    title: 'My camera',
    width: 480,
    height: 360,
    hideOriginView: true,
  }
);
```

> `hideOriginView` defaults to `true`. For separate-window mode, we generally recommend keeping the default, to avoid rendering the same video in both the main page and the popped-out window.

***

### Scenario 2: keep a floating camera window while sharing the desktop

Typical requirements:

* The user starts desktop sharing
* The main browser window may be minimized or covered by other apps
* The user still wants a small window of their own camera in the top-right corner to confirm how they appear on camera

Recommended combination:

* Use `LocalScreenTrack` for desktop sharing
* Use `LocalCameraTrack.enterPictureInPicture(...)` to put the camera into picture-in-picture

```typescript theme={null}
const localScreenTrack = srtc.createLocalScreenTrack(ScreenPresets['1080p']);
await localScreenTrack.startCapture({ contentHint: 'detail' });
localScreenTrack.addPlayView(document.querySelector('#screen-preview')!);
await srtc.publishLocalTrack(localScreenTrack, { desc: 'screen' });

const localCameraTrack = srtc.createLocalCameraTrack(CameraPresets['720p']);
await localCameraTrack.startCapture();
localCameraTrack.addPlayView(document.querySelector('#camera-preview')!);
await srtc.publishLocalTrack(localCameraTrack, { desc: 'camera_big' });

await localCameraTrack.enterPictureInPicture(
  document.querySelector('#camera-preview')!,
  {
    width: 320,
    height: 240,
    hideOriginView: true,
  }
);
```

> If the current browser supports `Document PiP`, the SDK uses it first; otherwise it falls back to the traditional `video PiP`. Traditional `video PiP` relies on the original `video` element, so the original view isn't hidden.

***

### Sync UI state with channel events

PiP / pop-out windows usually need to keep button labels, badges, or overlay hints in sync. We recommend using channel events for this rather than maintaining scattered state yourself.

```typescript theme={null}
srtc.onNotifyChannelEvent = (evt) => {
  switch (evt.type) {
    case ChannelEventType.TRACK_PIP_ENTER:
      console.log('Track entered picture-in-picture', evt.data);
      break;
    case ChannelEventType.TRACK_PIP_EXIT:
      console.log('Track exited picture-in-picture', evt.data);
      break;
    case ChannelEventType.TRACK_POPOUT_OPEN:
      console.log('Track popped out to a separate window', evt.data);
      break;
    case ChannelEventType.TRACK_POPOUT_CLOSE:
      console.log('Track closed its separate window', evt.data);
      break;
  }
};
```

***

### Cleanup when sharing ends

If the user clicks the browser's native "Stop sharing", the SDK fires `TRACK_ENDED`. At a minimum, clean up the sharing track itself:

```typescript theme={null}
srtc.onNotifyChannelEvent = async (evt) => {
  if (evt.type === ChannelEventType.TRACK_ENDED && evt.data === localScreenTrack) {
    await srtc.unpublishLocalTrack(localScreenTrack);
    localScreenTrack.removeAllPlayViews();
    localScreenTrack.stopCapture();
  }
};
```

> For the same `track`, `removePlayView(container)` and `removeAllPlayViews()` automatically clean up the picture-in-picture / pop-out window state associated with that track, so you don't need to call that track's `exitPictureInPicture` or `closePopOutWindow` again.
>
> If your product wants "when sharing ends, close the floating camera window too", that's a linkage policy at your app layer; you can additionally exit picture-in-picture for `localCameraTrack`, but it isn't a required step for SDK resource cleanup.

***

### Best practices

* `Picture-in-picture` suits small videos you want to "glance at any time", such as the local camera or self-preview
* `Pop-out windows` suit dual-screen collaboration and large displays, such as a remote shared desktop or the presenter's video
* If your UI needs to restore button states automatically, listen for the `TRACK_PIP_*` and `TRACK_POPOUT_*` events first