Jitsi Meet 新增多屏（Multi-screen）支持

Jitsi Meet 的参会者，一直以来都只是一个浏览器窗口、一种布局。可要是把这个会议放进一间四面墙都有显示屏的会议室，或者放在一台配了两块显示器的办公桌上，多出来的屏幕要么显示与第一块屏幕完全相同的内容，要么干脆什么都不显示。

多屏（Multi-screen） 改变了这一点。它是作为 Google Summer of Code 2026 项目开发出来的。现在，一个 Jitsi Meet 会话可以同时渲染到多块显示器上：一块屏幕显示当前发言人，另一块显示屏幕共享，第三块显示白板，而且无需重复加入会议。

Jitsi Meet 新增多屏（Multi-screen）支持 — 一场会议，三个界面：会议窗口，外加显示舞台画面和白板的第二屏幕。图片由各窗口的截图合成。

为什么不直接把房间打开两次呢？

目前很多会议室部署方案都是这么做的。虽然可行，但第二个标签页就相当于第二个参与者：它会出现在名单中，会订阅并解码每个音频流的独立副本，它的音频必须手动静音，而且两个窗口之间没有任何同步机制。

第二块屏幕就像一个渲染界面，叠加在你当前会议画面之上。只需一个桥接连接，一套媒体订阅，无需额外的音频路径。会议中的其他人根本察觉不到它的存在。

第二屏幕可以显示什么

舞台（stage），跟随当前发言人，并响应固定（pin）操作
所有参会者的平铺网格
屏幕共享，当有多人共享时可按参会者选择
白板
共享视频，可以是 YouTube，也可以是直链

以上每一项都是一种角色（role），而不是固定的某一路流。显示舞台的窗口会随着发言的人变化而自动切换指向，平铺网格也会随着参会者的进退而更新。

实现原理

有意思的难题在于：要把内容渲染进一个应用并不拥有的窗口。用 window.open 打开的弹窗是一个独立的文档，但 React portal 可以很自然地在这个弹窗里挂载一棵组件树。所以，第二屏幕并不是第二个应用，也不是任何东西的副本：它就是同一个 redux store、同一批组件，通过 portal 渲染进那个弹窗里。

有两件事需要特殊处理：

样式。 Emotion 会把 CSS 注入到它被创建时所对应的文档中，所以每个窗口都需要有自己指向自身文档 head 的样式缓存。没有它，portal 渲染出来的就是无样式的。
媒体。 把会议窗口的媒体流挂到另一个窗口里的 video 元素上，会跨越 realm 边界，所以每个 video 都要克隆（clone）轨道，并用弹窗自己的构造函数把克隆体包装起来。

clone = track.clone();
video.srcObject = new win.MediaStream([ clone ]);

克隆的代价很低，也不会带来额外的解码。它还让窗口有了由该功能掌控的生命周期：组件卸载时，克隆体就停止。

通过 iframe API 来驱动

多屏是为会议室设备而设计的：墙上挂着显示器，房间里没有鼠标。所以它是通过 iframe External API 来控制的，共一个命令和三个事件。API 的基础部分先落地，见 Emil Ivov 的 #17527，渲染层则构建在其之上。

// 把当前发言人放到一块显示器上……
api.executeCommand('setSecondScreen', {
    id: 'wall-left',
    source: { role: 'stage' }
});

// ……把屏幕共享放到另一块上。
api.executeCommand('setSecondScreen', {
    id: 'wall-right',
    source: { role: 'screenshare' },
    screen: 2
});

// 省略 source 就会关闭这个窗口。
api.executeCommand('setSecondScreen', {
    id: 'wall-right'
});

窗口 id 归嵌入方（embedder）所有，所以一间会议室的控制器可以按名称来寻址自己的显示器，并随时重新指定目标。有三个事件会回报状态：

secondScreenSourceChanged：某个窗口实际解析成了什么
secondScreenClosed：某个窗口消失了
secondScreenError：某个窗口无法打开，并附有六种错误码之一

从会议内部驱动

该命令覆盖的是事先配置好的显示器。更常见的情况是：某人在一场普通会议里，配了第二块显示器。为此，UI 中每一个“值得发送出去”的内容位置，现在都提供了发送选项：参会者在右键菜单里有 在第二屏幕显示（Show on second screen） 选项，屏幕共享和共享视频的缩略图在悬停时会出现一个按钮。再次点击则收回。

一次发送永远不会干扰你正在观看的内容。它会优先填满空闲的外接显示器，只有在所有显示器都已有内容后，才会复用窗口。应用内的触发器和 API 命令派发的是同一个动作，所以监听事件的嵌入方也能看到应用内的活动。

需要知道的事项

仅限 Chromium。 把窗口放到指定显示器上需要 Window Management API，目前这意味着基于 Chromium 的浏览器，例如 Chrome 和 Edge。
两项权限。 站点必须被允许打开弹窗并管理窗口。如果缺少第二项权限，窗口仍会打开，但落点由浏览器决定。
授权提示需要一次点击。 Chromium 只在用户手势之后才显示窗口管理授权提示。应用内触发器本身就有手势，而 API 命令没有，所以会议室设备应当通过策略预先授予该权限。
来源可以回来。 当某位参会者掉线时，他们的窗口会先等待几秒再关闭，因此短暂的重连不会把屏幕一起带走。

试一试

多屏默认关闭。部署方通过配置来选择启用：

secondScreen: {
    enabled: true
}

如果想不做任何部署就试一下，可以在 beta.meet.jit.si 的房间 URL 后加上 #config.secondScreen.enabled=true，然后打开任意参会者的右键菜单。命令、事件和错误码都记载在手册中。

这项工作是在 Google Summer of Code 2026 期间完成的，导师为 Tudor Avram 和 Cosmin-Alexandru Timis。感谢二位的评审——其中好几次评审改变的是设计，而不只是某一行代码；也感谢 Jitsi 社区，让这个夏天我得以投入一件自己日后会一直用下去的事情。