登录

我们如何将屏幕共享提速四倍

将 Cliqer 屏幕共享延迟从两秒多降至约半秒,背后的工程故事。

Cliqer Team

2026年9月3日 · 阅读时长 1 分钟

A software engineer reviewing a video latency graph on a monitor in a dimly lit office

屏幕共享延迟属于那种只有变差时才会被注意到的问题。演讲者点击切换到下一张幻灯片,现场观看共享屏幕的观众却要慢一拍半才看到。说不上坏了,只是不太对劲。在几个版本的迭代中,我们认真排查了 Cliqer 屏幕共享中延迟的来源,把持续延迟从两秒多降到了约半秒,提升约四倍。下面用通俗的语言讲讲我们是怎么做到的。

我们不打算用代号故弄玄虚,也不会假装有什么一招制胜的灵丹妙药。我们一共做了三项独立的修复,各自针对延迟藏身的不同环节,效果层层叠加。

要点速览
  • 三项修复叠加:消除重复编码、收紧缓冲区、为新观众缓存关键帧。
  • 持续延迟从两秒多降至约半秒,提升约四倍。
  • 无需更改任何设置。这些改进已自动内置于桌面应用的屏幕共享管线中。

屏幕共享为什么会卡顿

当您共享屏幕时,观众看到一帧画面之前必须完成三件事:您的电脑要捕获画面、将其编码为视频,再发送出去。其中任何一步都可能悄无声息地增加延迟,而且影响会层层累积。编码器慢一点,缓冲区保守一点,再等一等下一个完整帧更新,即使网络很快,加起来也很容易达到两三秒。

棘手之处在于,这些环节单独看都没有问题。捕获正常,编码正常,视频流也能到达。只是晚了,而「只是晚了」如果不逐个环节单独测量,很难诊断出来。

如果屏幕共享感觉卡顿,但通话中的其他一切都正常,请专门检查视频管线,而不是您的整体网络连接。从观众的角度看,这两种问题表现完全相同,但修复方法截然不同。

修复一:不再把同一画面编码两次

第一个延迟来源是无用功。屏幕共享和 NDI 共享在后台被编码了两次,每条输出路径各一次;而静止的幻灯片即使屏幕上没有任何变化,也在被持续重新编码。这让编码器负载翻倍,却没有带来任何视觉上的好处,也意味着管线总是比实际需要的更忙碌,从而让每一帧在队列中排得更靠后。

去掉重复的编码流程,并在画面没有变化时跳过重新编码,立刻释放出了可观的 CPU 余量。编码器上的争用减少,意味着每一帧真正需要编码的画面都能更快得到处理。

修复二:收紧缓冲区,同时不牺牲容错能力

第二个来源是位于编码器和网络之间的缓冲区,它的作用是吸收短暂的网络波动,让线路上的卡顿不会变成屏幕上的卡顿。这类缓冲区本质上是一种权衡:太小,轻微的波动就会造成明显的画面故障;太宽裕,就会为了防范以后可能出现的问题,给每一帧都增加延迟。

此前缓冲区设置得很宽裕,这意味着在常见情况下,为了防范罕见情况,它给每一帧都增加了延迟。收紧之后,最坏情况下的延迟从几秒降到了远低于一秒,同时仍能平稳度过短暂的网络波动,不出现明显的画面故障。这类修复在代码差异里看起来只是改了个小数字,实际上却是在判断:您更愿意接受哪一种失败模式。

修复三:不再让新观众等待下一个关键帧

第三项修复针对一个具体而令人头疼的时刻:有人加入一个已经在进行中的共享时会发生什么。视频压缩的原理是只偶尔发送完整帧(称为关键帧),中间穿插成本更低的「与上一帧相比有何变化」的帧。中途加入的观众在收到可作为基准的关键帧之前,无法解读这些中间帧;而以前这意味着要等待下一个预定的关键帧,最长可达三秒。

修复方法是缓存最近的关键帧,并在新订阅者加入的那一刻立即交给对方,而不是让其等待计划中的下一个关键帧。结合我们屏幕共享文档中介绍的基于间隔的帧定时机制,新观众现在加入共享后几毫秒内就能看到视频,而不必等待最长三秒的下一个关键帧。

将三项修复叠加在一起,大多数人从未完全信任过的两秒多持续延迟变成了约半秒,提升约四倍,同时 CPU 和带宽占用都比以前更少。完整帧率在这里同样重要:此前无论来源如何,节目视频都被悄悄限制在约每秒 31 帧,因此现在 60fps 的共享在接收端看起来和在演讲者自己屏幕上一样流畅。

这对正在演示的您意味着什么

这一切都不需要您更改任何设置。改进已内置于桌面应用的屏幕共享管线中,无论您是在小房间里共享单个显示器,还是运行包含多个信号源的完整 Studio 制作(包括依赖快速、可预测画面的 vMix 工作流),都同样适用。在 Cliqer 3 中,Mac 上的 Studio 视频采用零拷贝:摄像头帧、信号源和 Program 都保留在 GPU 内存中,硬件编码器直接从 GPU 表面读取 Program。Cliqer 3 还会在 Studio 的状态栏中始终显示 Program 帧率、GPU 和 CPU 负载,让您在演出中随时亲自查看帧率。如果您想在降低延迟的基础上进一步权衡画质与带宽,屏幕共享设置涵盖编解码器选择、分辨率和码率;桌面版 2.2.0 还新增了直接在共享中包含系统音频或麦克风音频的选项。

对于延迟最明显的混合场景,尤其是远程演讲者一边观看共享屏幕一边实时做出反应的情况,可以结合阅读我们的指南解决混合会议中的屏幕共享延迟,以及我们的解读文章:为什么以毫秒计的演示遥控器延迟在控制端和视频端同样重要。

其余的延迟来自哪里

屏幕共享只是整个链路中的一段。另一段是网络路径本身:演讲者与观众之间的连接是直连还是中继,以及在阻止点对点直连流量的网络上会发生什么。我们在TURN 服务器详解和WebRTC 安全吗中介绍了这方面的内容,包括为什么在某些网络上这部分延迟永远无法完全消除。

环节优化前优化后
编码重复编码流程,静态帧持续重新编码单次编码,跳过未变化的帧
缓冲缓冲区宽裕,每一帧都增加延迟缓冲区收紧,仍能吸收短暂波动
新观众加入最长等待 3 秒以获取下一个关键帧立即发送缓存的关键帧
持续延迟超过 2 秒约 0.5 秒

TURN 服务器详解

为什么剩余的部分延迟来自网络路径,而不是编码器。

屏幕共享延迟解决方法

更多针对远程演讲者回看屏幕的混合场景的修复方法。

屏幕共享设置

编解码器、分辨率和码率设置,用于权衡画质与带宽。

以毫秒计的演示遥控器延迟

为什么控制端延迟与视频画面本身同样重要。

常见问题

亲自试试

感受差异最快的方法,就是共享一次屏幕,然后看看对方看到画面时的表情。免费下载 Cliqer,在您自己的设备上试试屏幕共享,或者查看屏幕共享的完整功能,并在价格页面比较各个方案。

engineeringscreen sharinglatencyperformance

由Cliqer Team撰写

我们打造了 Cliqer,这款互联网遥控器正在全球各地的舞台、教室和会议室中使用。

用 Cliqer 掌控您的下一场活动

任意幻灯片,任意手机,随时随地。桌面应用托管房间,演讲者只需打开链接。

继续阅读

更多产品动态,助力您的下一场活动

A presenter holds a phone remote: one half seen through a thermal camera glowing hot, the other half cool in mint stage light
产品动态

我们为何抛弃 Flutter 应用,基于 Rust 核心原生重建 Cliqer Remote

我们用 Flutter 构建了 Cliqer Remote,在真实手机上实测后,又基于同一个 Rust 核心原生重建:耗电减半,不再发热。这里是数据与经验。
A dedicated server rack glowing mint in a dark data hall
产品动态

我们为何将 Cliqer 的实时服务迁离 Cloudflare(以及为何我们依然是它的粉丝)

在 Cloudflare 边缘运行的四个月:哪些地方出了问题,我们为应对构建了什么,以及 Cliqer 为何如今运行在我们自己的专用服务器上。
A bright hybrid meeting room with a camera on a tripod and a laptop running Cliqer Studio
现场制作

Cliqer vs Ecamm Live:哪款直播工作室更适合您的节目?

公平对比 Cliqer 与 Ecamm Live:支持 Mac 和 Windows 的 Studio、Live、Timer 与手机遥控,对比仅限 Mac 的直播工作室。
简报

赶在您的下一场活动之前,抢先获取下一篇指南

为演讲者、AV 团队和活动团队提供实用指南,以及真正重要的 Cliqer 版本更新。绝无垃圾邮件,一键即可退订。