基于webrtc的前端录屏与直播

我在腾讯主导了一个用于用户行为监控与回放的项目,其中,通过录制前端DOM的变化,实现用户界面的变化。和rrweb不同,我们没有使用MutationObserver方案进行录制,这个方案需要解决如何获取被移除节点的路径问题,非常复杂,且MutationObserver具有兼容性问题,低版本浏览器不支持,另外由于MutationObserver基于微任务进行响应,响应过快,导致一些性能问题,另外还有不可预测的丢帧问题。我们采用了另外一套更加缜密的DOM变化记录方案,但由于内部项目暂时不便公开。在除了web录屏与回放的研究之外,我还关注到滴滴内部开源了一套原生APP的录屏方案。另外,除了基于DOM的录屏方案外,我还在寻找另外的更高效的录屏方案,因为基于js的录屏方案,会带来不可避免的性能问题,以及丢失数据问题。在一次偶然冲浪过程中,我发现谷歌已经通过chrome开放了录屏接口,也就是getDisplayMedia,于是进行了一番研究,并通过本文记录下来。

什么是WebRTC?

getDisplayMedia是webrtc整体标准中的一个接口,要了解webrtc的入门信息,可以移步《WebRTC点对点应用架构研究》这篇2018年发表的博文,这篇文章可以作为入门了解webrtc及其基本开发步骤的知识文章。

在上述文章之上,我们再去理解webrtc,可以这么理解:webrtc是一套客户端点对点流式信息传播的技术方案。其中我的新认识在于“流式信息”这个点,以前,我把重点放在“点对点”上,但逐渐我发现,但凡基于流式信息的传播,都可以在webrtc标准下去讨论。这里的流式信息,主要是指基于音视轨的实时数据流。说白了,就是音频和视频实时数据。

而本文讨论的屏幕录制,就属于这一范畴。因此,录屏接口也被放在webrtc整体框架下面。

getDisplayMedia与直播

从接口名称可以看出,这是一个获取显示器实施音视频数据的接口。在我最早的文章中并没有介绍这个接口,当时并没有注意到它。我们看下它的兼容性。

可以看出来,它的兼容性并不好,IE直接pass,手机端无一支持。但考虑到实际场景,录屏基本上也只会在PC端有应用场景。

关于getDisplayMedia这个接口的具体用法,可以参考MDN。它的使用超级简单:

navigator.mediaDevices.getDisplayMedia(constraints).then((stream) => {
  // ...
})

上面代码会执行webrtc惯用步骤,弹出与用户之间的交互对话框,只有用户允许之后,才能进行录屏。它返回一个promise,then里面接住一个stream,这个stream就是被录制的屏幕音视流。我们可以把这个流塞到一个video标签上,就可以看到录制的实时效果了。

document.querySelector('video#player').srcObject = stream

这里的stream是一个MediaStream类型的流,这种流的特征是,它拥有多个轨,也就是tracks。而在我文章开头的文章里面有代码演示,通过peer.addTrack就可以完成节点之间的点对点传输的对接工作。也就是说,我们将前文的peer相关的知识和这里的知识结合,就可以马上做一款录屏直播应用。

stream.getTracks().forEach((track) => {
  peer.addTrack(track, stream)
})

这一切看上去都非常简单不是吗?

用户行为监控

由于webrtc在启动能力前,会有原生的chrome窗口弹出来询问用户,且在开启getDisplayMedia之后会有一个状态条,所以在整个的操作中会有一些生硬,用户有明显的知道自己的屏幕正在被录制。因此,利用webrtc进行录屏,是一种有感录制,和我之前一直在做的无感录屏稍有不同。

因此,此类用户行为监控更适合用在测试场景下,或者明确授权情况下。我们来看下具体的实现过程。

在通过getDisplayMedia获得stream之后,我们需要通过MediaRecorder对stream进行录制。MediaRecorder也是webrtc的接口,你可以通过MDN了解它的具体用法。它可以对一个stream进行录制,并生成blob格式的目标数据。但凡webrtc相关的stream,都可以被MediaRecorder录制出来。一旦理解了stream的本质,那么对录制也会理解不少:录制就是在流上创建截面序列,也就是采集音视频的过程,因此,我们需要配置一些采样信息,通过配置不同的采样信息,就可以得到不同画质、音质、流畅度的结果。

recorder = new MediaRecorder(stream, { mimeType: "video/webm; codecs=vp9" })
recorder.ondataavailable = handleRecord
recorder.onerror = e => console.log(e)
recorder.start()

其中,ondataavailable是一个回调,当需要产生一个视频数据时,它的回调函数会接受一个BlobEvent事件,而该事件中有一个data属性,内容为一个Blob。什么时候会触发这个事件呢?有两种情况,一种是调用recorder.requestData()方法,那么这个回调就被触发一次,此时会产生一个blob。另一种是调用recorder.stop()时,也会产生一个blob。每次产生的blob都是从上一次产生到当前这一时刻之间的录制片段,因此,如果中途不调用requestData方法,那么当你调用stop方法的时候,全部过程就会被记录下来。

function handleRecord(e) {
    if (event.data.size <= 0) {
        return
    }

    chunks.push(event.data)
}

但作为用户行为监控的一个部分,很显然,我们更希望当用户的某个操作产生了错误的时候,才上报对应的录制视频。因此,我可能更倾向按照一定的策略来生成一段一段的视频,在需要的时候,通过前后端的交互,完成视频传输。

blob = new Blob(chunks, {
    type: "video/webm"
})

由于我们拥有indexedDB这个利器,可以将blob存在本地,在需要的时候,通过webrtc点对点传输的特质,直接将视频传输给运维人员观看。这样可以解决服务端存储占用过多的问题。另外,ffmpeg已经出了webassembly版本,这让我们可以在前端浏览器中,对视频进行转化、裁剪、截图、修改、压缩等。

结语

Webrtc是web标准中关于流式数据实时传输的重要标准,而录屏能力,在直播、网课、用户行为监控等方面,都给我提供了一定的想象空间。我在最新一期的《Robust》中提到音视频应用、5G等基础设施层面、消费层面的相关逻辑,新的一年在webrtc这个点上,会给我们带来更多想象空间。如果你也对相关领域感兴趣,不妨一起来试试。

2021-01-10 162 ,

为价值买单

本文价值1.62RMB