桌面分享编码技术的演变

  桌面分享编码技术的演变 

by 技术怪咖 汤军

导读：桌面分享从功能上应该怎么分？数据编码的技术演变又是如何演变的？资深工程师汤军结合自己多年的实操经验，给出独到见解

由于最近几年的工作分别在“在线教育”和“视频会议”领域，在这两个领域对用户而言最重要的功能除了语音就是桌面分享，恰巧这也是我所擅长的领域。

桌面分享从功能上可以拆分为屏幕抓取与数据编码两个大的方面。其中屏幕抓取，主要获取数据源，在当前的机器的运算能下，该功能已不再是瓶颈，所以我们下面主要聊聊数据编码的技术演变。

桌面分享功能脱胎于远程桌面技术

最早的远程桌面是基于命令行界面的模拟终端。此时并不涉及到抓屏与编码，终端与远端机器之间通讯的是shell命令，以及命令的执行结果，对机器的性能以及网络代码的需求很低。

随着Win95系统上市并且成功引爆图形界面操作系统市场，受限于当时机器的性能以及网络带宽，在相当长一段时间中都没有出现针对图形操作系统的远程桌面工具。直到Windows2000上市，微软在其中提供了远程桌面组件，才第一次实现了基于图形界面的远程桌面。

早期的图形界面的分辨率比较低（800*600），颜色数比较少（以16位色居多，24位真彩色很少见）。然而就算这样，屏幕数据量（937KB）对于当时的宽带网络（ADSL拨号上网，上传带宽512kb~1Mb）也是个沉重的负担，理论上以当时的网络，传递一帧未压缩的屏幕数据需要用时8~16秒，这显然无法接受。为了能更快的将桌面图形快速的通过网络传递到终端，桌面数据的压缩编码就应运而生了。

桌面数据压缩之初，主要被用来解决帧数据过大这个问题。所以首先被应用的就是当时很流行的图片数据有损压缩方法（JPG），该压缩算法在图片质量下降不是很明显的情况下，压缩后的图片仅为原大小的10%。在使用了JPG压缩算法后，对于观看远端静态文档暂时勉强够用。

为了能进一步减少传输间隔，在没办法减少每一帧数据大小的情况下，我们问自己，每一次都传输完整的帧数据，就是是否必须？经过分析，我们发现桌面发生完全变化的概率很少，绝大部分都是局部变化，如：按钮获取焦点，某个控件数据获得更新等。

（图1）

在实际使用中发现，对于纯文本展示（文本文件、PPT、静态网页等），使用JPG方法压缩后字体的背景不是很干净。放大图片后发现文本显示的边缘与背景融合处使用了渐变色过渡。

而JPG压缩会丢失这部分信息的细节。对于纯文本展示（文本文件、PPT、静态网页等）的桌面数据观察发现，大部分为少数颜色的文本加大面积单色的背景。对于这种类型数据恰巧可以使用基于调色盘的无损压缩。我们又再次改进了之前的编码策略。在已经判定块需要编码的情况下，再分析块中使用的颜色数，依据颜色数的不同选择不同的编码方式。

随着机器性能的持续提升，显示器的分辨率越来越高，1080P全高清成为主流，4K屏也不鲜见，并且越来越多。用户在使用PPT等展示数据时，复杂背景、植入的图表（视频），翻页的动画效果，全都越来越多。网络带宽虽然也有提升，但完全跟不上机器性能提升的速度。上述的编码方案在桌面短时间发生剧烈改变时，产生了大量的爆发数据。

而按上述方案，后续数据的显示又必须依赖前面数据的更新。由于爆发数据导致的数据积压，使得桌面分享实时性越来越差。分析上述场景，我们发现在用户切换PPT页面的动画播放期间，可能产生了5帧画面，并且这5帧画面的变化都比较大，如果一一进行编码传输，会导致传输在短期出现一个峰值，超出了带宽的承载能力。但是相对于页面切换动画，观看者更期望能更快的看到下一页的PPT。

为此，我们引入了延迟编码的策略，当桌面两帧数据之间的差异很大的时候，我们暂存待编码的帧，等待下一帧数据，同时开始计时。下一帧数据获取后，该帧和待编码的帧之间的差异如果很大，用该帧代替待编码帧，继续等待；如果该差异比较小，丢弃待编码的帧，编码当前帧数据并发送到观看端。

如果两帧之间的差异一直很大，那么当计时器（500毫秒）超时后，编码当前等待帧，并复位定时器。在全时云会议的开发项目中，我们设计并实现了上面的延迟编码策略，显著加快了复杂PPT页面切换时的观看延迟。

从2007年以来，视频流媒体技术得到了长足的进步。从早期H261、H263到现在的H264，以及为了应对目前越来越普及的超高清（4k分辨率）视频而出现的H265和VP9、VP10编码。

而用户对桌面共享的流畅性的期望越来越向视频的流畅度靠拢，这使得我们不得不考虑，桌面数据的压缩方式是否能使用视频的压缩方法。我们发现，桌面数据走视频流的模式对于持续变化的桌面分享有显著的削峰填谷效果。