在基于WebRTC做屏幕录制时，开发者往往只关注视频流本身的清晰度和帧率，却容易忽略一个影响观感的关键细节：鼠标轨迹和视频画面是否对齐。如果光标位置明显滞后于实际操作，或者回放时鼠标在帧与帧之间“瞬移”，观众就会很难理解录制者的意图。这个问题本质上不是编码参数没调好，而是时间基准和事件采集链路没有统一。
为什么鼠标和视频会不同步
WebRTC的屏幕采集通常依赖getDisplayMedia接口，它返回的是一个MediaStream，里面只包含视频轨和可选的音频轨。也就是说，浏览器把屏幕像素抓出来编码进视频帧，但并不会在帧里嵌入“此时鼠标在坐标(x,y)”这样的信息。鼠标作为一个独立的输入设备，它的移动事件是通过DOM的mousemove或者Pointer Events来获取的，这两套机制的触发频率和采集时机完全不同。
视频帧的采集受显示器刷新率、浏览器合成节奏以及编码器缓冲的影响，可能稳定在30fps或60fps；而鼠标事件则由系统指针采样率决定，通常远高于视频帧率，且不会和某一帧的捕获时刻精确重合。若简单地把最近一次mousemove的坐标直接画在视频上，由于两者的时钟来源虽然都是同一台机器，但事件循环调度存在抖动，长时间录制后累积误差就会显现。此外，不同操作系统对光标绘制的处理也不同，有些会在合成层直接画光标，导致你即便隐藏了系统光标，视频里依然有影子。
基于统一时间戳的同步采集方案
要解决漂移，核心思路是让视频帧和鼠标事件共享同一个高精度时间源，并在后期按时间对齐。在采集阶段，我们通过performance.now()获取时间戳，它提供亚毫秒级且单调递增的时间，适合做本地同步。视频帧可以通过requestVideoFrameCallback拿到每一帧的呈现时间，鼠标事件则在回调里记录坐标与同一时间轴上的时间戳。
下面是一段采集端记录鼠标轨迹的示例代码，它把每个鼠标事件连同时间戳存入数组，供后续渲染或合成使用：
// 使用高精度时间轴记录鼠标轨迹
const mouseTrace = [];
document.addEventListener('mousemove', (event) => {
const timestamp = performance.now();
mouseTrace.push({
t: timestamp,
x: event.clientX,
y: event.clientY
});
});
// 限制数组长度，避免内存无限增长
setInterval(() => {
const now = performance.now();
while (mouseTrace.length > 0 && mouseTrace[0].t < now - 5000) {
mouseTrace.shift();
}
}, 1000);
这段代码没有依赖任何视频接口，只是先把原始轨迹按时间存下来。它的好处是解耦了输入和输出，后面无论是实时绘制还是离线合成，都能根据帧时间从mouseTrace里找到最接近的坐标点。需要注意，mousemove在高刷新率鼠标上可能一秒触发几百次，因此要做节流或时间窗口清理，否则内存和后续查找开销都会变大。
利用视频帧回调对齐光标位置
现代浏览器提供了requestVideoFrameCallback，它能在每个视频帧被提交到屏幕时给出准确的呈现时间戳。我们可以在这个回调里，根据当前帧的时间去鼠标轨迹里找对应位置，而不是用上一次事件的坐标。这样即使鼠标事件比帧密，也能保证画上去的光标是“这一帧时刻”应该处的位置。
以下示例展示如何将轨迹绘制到覆盖层画布上：
const video = document.querySelector('video');
const canvas = document.querySelector('canvas');
const ctx = canvas.getContext('2d');
function findNearest(timestamp) {
// 简单线性查找，生产环境可用二分
let best = mouseTrace[0];
for (const item of mouseTrace) {
if (item.t <= timestamp) {
best = item;
} else {
break;
}
}
return best;
}
video.requestVideoFrameCallback(function (now, metadata) {
const frameTime = metadata.mediaTime * 1000 + performance.timeOrigin - performance.now();
const pos = findNearest(performance.now());
ctx.clearRect(0, 0, canvas.width, canvas.height);
if (pos) {
ctx.beginPath();
ctx.arc(pos.x, pos.y, 8, 0, Math.PI * 2);
ctx.fillStyle = 'rgba(255, 0, 0, 0.8)';
ctx.fill();
}
});
这里用metadata.mediaTime配合时间基准换算，尽量贴近视频帧真实采集时刻。实际工程中，如果是在录制阶段就要把光标烧录进视频，而非仅覆盖显示，那就需要在MediaStream处理链路里用canvas.captureStream()把绘制了光标的画布和原始屏幕流做合成，再传给MediaRecorder。该方式的优点是回放文件自带光标，缺点是增加了实时绘制和编码开销。
直接使用浏览器光标捕获的利弊
部分浏览器在getDisplayMedia的video约束里支持cursor: 'always'或'motion'，意思是把系统光标直接画进视频帧。这样做不需要任何额外代码，光标天然和画面同帧，不存在同步问题。
但局限性很明显：首先，Firefox和Safari对这类约束的支持度和表现形式不一致，可能导致某些环境下光标不显示；其次，你无法控制光标的样式、大小和高亮效果，对于教学录制希望突出点击圆环的需求无能为力；最后，如果用户系统设置了自定义光标或放大镜辅助功能，视频里也会原样带入，不一定符合录制预期。因此，追求可控性的项目通常选择隐藏系统光标，用前面说的自绘方案。
合成阶段的离线校正思路
如果录制时只存了原始视频和独立的鼠标轨迹日志，也可以在事后用ffmpeg或WebCodecs做离线合成。离线处理的优势是可以用更精确的插值算法，比如根据前后两个鼠标事件时间做线性插值，算出任意视频帧时刻的亚像素坐标，让光标移动看起来更平滑。
下表对比了几种常见策略的特点：
| 策略 | 同步精度 | 兼容性 | 定制能力 |
|---|---|---|---|
| 浏览器原生光标捕获 | 高，同帧 | Chromium较好，其他弱 | 低 |
| 实时自绘叠加层 | 中高，依赖时间对齐 | 全部现代浏览器 | 高 |
| 离线轨迹合成 | 最高，可插值 | 取决于合成工具 | 高 |
从工程落地角度看，如果产品只跑在Chromium内核且不需要花哨光标，直接用原生捕获最省事；如果是跨端Web应用或需要品牌化光标样式，实时自绘配合统一时间戳是平衡复杂度和效果的做法；而当录制内容用于高质量教程发布时，离线合成能进一步消除抖动。
避免常见误区
一个容易被忽略的误区是认为setInterval或setTimeout可以拿来给鼠标和视频“对表”。这两个定时器受事件循环阻塞影响很大，在页面繁忙时偏差可能到几十毫秒，拿来同步视觉元素只会让问题更糟。另一个误区是在mousemove里直接读取视频当前时间并绘制，却忘了视频可能有缓冲延迟，你读到的是播放时间而非采集时间，也会导致offset。
正确做法是坚持用performance.now()这类与渲染无关的时间轴，并且明确区分“采集端时间”和“播放端时间”。在本地实时录制场景下两者接近，但一旦涉及网络传输或文件回放，就必须以媒体自身的时间戳为准，而不是以代码跑到的时刻为准。理清这一层，鼠标与视频帧的精确同步才真正可控。
WebRTCscreen_capturemouse_tracking修改时间：2026-08-01 13:24:38