摄像头视频采集压缩及传输 基本原理

摄像头视频采集压缩及传输

引言 ：

摄像头基本的功能还是视频传输，那么它是依靠怎样的原理来实现的呢？所谓视频传输:

就是将图片一张张传到屏幕，由于传输速度很快，所以可以让大家看到连续动态的画面，就像放电影一样。一般当画面的传输数量达到 每秒24帧 时，画面就有了连续性。

下边我们将介绍摄像头视频采集压缩及传输的整个过程。

一．摄像头的工作原理（获取视频数据）

摄像头的工作原理大致为：景物通过 镜头（LENS） 生成的 光学图像 投射到 图像传感器 表面上，然后转为 电信号 ，经过 A/D （模数转换）转换后变为 数字图像信号 ，再送到 数字信号处理芯片 （DSP）中加工处理，再通过 USB接口 传输到电脑中处理，通过显示器就可以看到图像了。下图是摄像头工作的流程图：

注1：图像传感器（SENSOR）是一种半导体芯片，其表面包含有几十万到几百万的光电二极管。光电二极管受到光照射时，就会产生电荷。

注2：数字信号处理芯片DSP（DIGITAL SIGNAL PROCESSING）功能：主要是通过一系列复杂的数学算法运算，对数字图像信号参数进行优化处理，并把处理后的信号通过USB等接口传到PC等设备。

1. ISP（image signal processor）（镜像信号处理器）

2. JPEG encoder（JPEG图像解码器）

3. USB device controller（USB设备控制器）

而视频要求将获取的视频图像通过互联网传送到异地的电脑上显示出来这其中就涉及到对于获得的视频图像的传输。

在进行这种图片的传输时，必须将图片进行压缩，一般压缩方式有如H.261、JPEG、MPEG等，否则传输所需的带宽会变得很大。大家用RealPlayer不知是否留意，当播放电影的时候，在播放器的下方会有一个传输速度250kbps、400kbps、1000kbps…画面的质量越高，这个速度也就越大。而摄像头进行视频传输也是这个原理，如果将摄像头的分辨率调到640×480，捕捉到的图片每张 大小约为50kb左右，每秒30帧，那么摄像头传输视频所需的速度为50×30/s＝1500kbps＝1.5Mbps。而在实际生活中，人们一般用于网络视频聊天时的分辨率为320×240甚至更低，传输的帧数为每秒24帧。换言之，此时视频传输速率将不到300kbps，人们就可以进行较为流畅的视频传输聊天。如果采用更高的压缩视频方式，如MPEG-1等等，可以将传输速率降低到200kbps不到。这个就是一般视频聊天时，摄像头所需的网络传输速度。

二．视频压缩部分

视频的压缩 是视频处理的核心，按照是否实时性可以分为非实时压缩和实时压缩。而视频传输（如QQ视频即时聊天）属于要求视频压缩为实时压缩。

下面对于视频为什么能压缩进行说明。

视频压缩是有损压缩，一般说来，视频压缩的压缩率都很高，能够做到这么高的压缩率是因为视频图像有着非常大的 时间和空间的冗余度 。所谓的 时间冗余度 指的是两帧相邻的图像他们相同位置的像素值比较类似，具有很大的相关性，尤其是静止图像，甚至两帧图像完全相同，对运动图像，通过某种运算（运动估计），应该说他们也具有很高的相关性；而空间相关性指的是同一帧图像，相邻的两个像素也具备一定的相关性。这些相关性是视频压缩算法的初始假设，换句话说，如果不满足这两个条件（全白噪声图像，场景频繁切换图像等），视频压缩的效果是会很差的。

去除时间相关性的关键算法是运动估计，它找出当前图像宏块在上一帧图像中最匹配的位置，很多时候，我们只需要把这个相对坐标记录下来，就够了，这样就节省了大量码字，提高了压缩率。视频压缩算法中，运动估计永远是最关键最核心的部分。去除空间相关性是通过DCT变换来实现的，把时域上的数据映射到频域上，然后对DCT系数进行量化处理，基本上，所有的有损压缩，都会有量化，它提高压缩率最明显。

图像的原始文件是比较大的，必须经过图像压缩才能够进行快速的传输以及顺畅的播放。而压缩比正是来衡量影像压缩大小的参数。 一般来说，摄像头的压缩比率大都是5:1。也就是说，如果在未压缩之前30秒的图像的容量是30MB，那么按照摄像头5:1的压缩比率来对图像进行压缩以后，它的大小就变成了6MB了。

主要的视频压缩算法包括：M-JPEG、Mpeg、H.264、Wavelet（小波压缩）、JPEG 2000、AVS。

基本上视频压缩的核心就这些。

三．视频传输部分

为了保证数字视频网络传输的实时性和图像的质量，传输层协议的选择是整个设计和实现的关键。Internet在IP层上使用两种传输协议：一种是TCP(传输控制协议)，它是面向连接的网络协议；另一种是UDP(用户数据报协议)，它是无连接的网络协议。

TCP 传输 ：TCP（传输控制协议）是一种面向连接的网络传输协议。支持多数据流 *** 作，提供流控和错误控制，乃至对乱序到达报文的重新排序，因此，TCP传输提供了可靠的数据传输服务。

使用TCP传输的一般的过程：

客户机向服务器发出连接的请求后，服务器接收到后，向客户机发出连接确认，实现连接后，双方进行数据传输。

UDP 传输 ： UDP（用户数据报协议）是一种无连接的网络传输协议。提供一种基本的低延时的称谓数据报的传输服务。不需要像TCP传输一样需预先建立一条连接。UDP无计时机制、流控或拥塞管理机制。丢失的数据不会重传。因此提供一种不可靠的的应用数据传输服务。但在一个良好的网络环境下如 局域网内，使用UDP传输数据还是比较可靠，且效率很高。

IP 组播技术： 组播技术是一种允许一个或多个发送者发送单一或多个发送者的数据包到多个接收者的网络技术。组播源把数据报发送到特定的组播组，而只有加入到该组播组的主机才能接收到这些数据包。组播可大大节省网络宽带，因为无论有多少个目标地址，在整个网络的任何一条链路上只船送单一的数据包。

1.TCP/IP 协议和实时传输

TCP/IP协议最初是为提供非实时数据业务而设计的。IP协议负责主机之间的数据传输，不进行检错和纠错。因此，经常发生数据丢失或失序现象。为保证数据的可靠传输，人们将TCP协议用于IP数据的传输，以提高接收端的检错和纠错能力。当检测到数据包丢失或错误时，就会要求发送端重新发送，这样一来就不可避免地引起了传输延时和耗用网络的带宽。因此传统的TCP/IP协议传输实时音频、视频数据的能力较差。当然在传输用于回放的视频和音频数据时，TCP协议也是一种选择。如果有足够大的缓冲区、充足的网络带宽，在TCP协议上，接近实时的视音频传输也是可能的。然而，如果在丢包率较高、网络状况不好的情况下，利用TCP协议进行视频或音频通信几乎是不可能的。

TCP和其它可靠的传输层协议如XTP不适合实时视音频传输的原因主要有以下几个方面：

1 .TCP的重传机制

我们知道，在TCP/IP协议中，当发送方发现数据丢失时，它将要求重传丢失的数据包。然而这将需要一个甚至更多的周期（根据TCP/IP的快速重传机制，这将需要三个额外的帧延迟），这种重传对于实时性要求较高的视音频数据通信来说几乎是灾难性的，因为接收方不得不等待重传数据的到来，从而造成了延迟和断点（音频的不连续或视频的凝固等等）。

2 . TCP的拥塞控制机制

TCP的拥塞控制机制在探测到有数据包丢失时，它就会减小它的拥塞窗口。而另一方面，音频、视频在特定的编码方式下，产生的编码数量（即码率）是不可能突然改变的。正确的拥塞控制应该是变换音频、视频信息的编码方式，调节视频信息的帧频或图像幅面的大小等等。

3 . TCP报文头的大小

TCP不适合于实时视音频传输的另一个缺陷是，它的报文头比UDP的报文头大。TCP的报文头为40个字节，而UDP的报文头仅为12个字节。并且，这些可靠的传输层协议 不能提供时间戳（Time Stamp）和编解码信息（Encoding Information） ，而这些信息恰恰是接收方（即客户端）的应用程序所需要的。因此TCP是不适合于视音频信息的实时传输的。

4 . 启动速度慢

即便是在网络运行状态良好、没有丢包的情况下，由于TCP的启动需要建立连接，因而在初始化的过程中，需要较长的时间，而在一个实时视音频传输应用中，尽量少的延迟正是我们所期望的。

由此可见，TCP协议是不适合用来传输实时视音频数据的，为了实现视音频数据的实时传输，我们需要寻求其它的途径。

2.RTP 协议适合实时视音频传输

RTP（Real-Time Transport Protocol）/RTCP（Real-Time Transport Control Protocol）是一种应用型的传输层协议，它并不提供任何传输可靠性的保证和流量的拥塞控制机制。它是由IETF（Internet Engineering Task Force）为视音频的实时传输而设计的传输协议。RTP协议位于UDP协议之上，在功能上独立于下面的传输层（UDP）和网络层，但不能单独作为一个层次存在，通常是利用低层的UDP协议对实时视音频数据进行组播（Multicast）或单播（Unicast）,从而实现多点或单点视音频数据的传输。

UDP是一种无连接的数据报投递服务，虽然没有TCP那么可靠，并且无法保证实时视音频传输业务的服务质量（QoS）,需要RTCP实时监控数据传输和服务质量，但是，由于UDP的传输延时低于TCP，能与音频和视频流很好地匹配。因此，在实际应用中，RTP/RTCP/UDP用于音视频媒体，而TCP用于数据和控制信令的传输。

总结 ：如果接收端和发送端处于同一个局域网内，由于有充分的带宽保证，在满足视频传输的实时性方面，TCP也可以有比较好的表现，TCP和基于UDP的RTP的视频传输性能相差不大。由于在局域网内带宽不是主要矛盾，此时视频数据传输所表现出来的延时主要体现为处理延时，它是由处理机的处理能力以及采用的处理机制所决定的 。但是当在广域网中进行视频数据传输时，此时的传输性能极大地取决于可用的带宽，由于TCP是面向连接的传输层协议，它的重传机制和拥塞控制机制，将使网络状况进一步恶化，从而带来灾难性的延时。同时，在这种网络环境下，通过TCP传输的视频数据，在接收端重建、回放时，断点非常明显，体现为明显的断断续续，传输的实时性和传输质量都无法保障。相对而言，采用RTP传输的视频数据的实时性和传输质量就要好得多。

四．视频图像的异地显示

当压缩过的视频通过互联网传输到异地的时候，对于互联网传输过来的视频信息，首先是要进行解码，然后才是显示。解码的芯片有一定的性能要求，比编码器低些，但是毕竟是视频数据处理，通用的芯片（不支持MMX等多媒体指令）可能会比较吃力。显示设备主要有电视、监视器和显示器，他们的信号接口是不一样的，电视监视器是模拟的电信号，显示器的输入应该是数字信号。

以上是摄像头如何获取图像数据及获取的数据存放在什么地方，如何压缩和传输及如何在异地释放和播放出来的整个过程

UDP的特点：

UDP是一个无连接协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。

在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包而言UDP的额外开销很小。

吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

虽然UDP是一个不可靠的协议，但它是分发信息的一个理想协议。例如，在屏幕上报告股票市场、显示航空信息等等。

UDP也用在路由信息协议RIP（Routing Information Protocol）中修改路由表。在这些应用场合下，如果有一个消息丢失，在几秒之后另一个新的消息就会替换它。UDP广泛用在多媒体应用中。

扩展资料：

适用场合：

在选择UDP作为传输协议时必须要谨慎。在网络质量令人十分不满意的环境下，UDP协议数据包丢失会比较严重。但是由于UDP的特性：

它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。比如我们聊天用的ICQ和QQ就是使用的UDP协议。

参考资料来源：百度百科——UDP

事后想来，芯片验证工程师Lynda觉得进腾讯有点“草率”了。

作为一个在半导体行业工作过多年的资深工程师，Lynda第一次看到腾讯发布芯片岗位需求时，略感到一丝惊讶。2019年1月她带着好奇加入这家互联网大厂，准备撸起袖子，大干一场。

面试时，主导芯片设计工作的Henry给她打过一剂预防针：“我们是从零开始做芯片。”Lynda试图代入鹅厂一贯的低调来理解这句话，但随即便在第一天上班时被跟同事的对话震到了：

-“我们的仿真工具呢？” -“没有，还在谈。”

-“验证环境怎么说？” -“还……没有。”

-“那……验证流程呢？-“这个……也没有。“

对于一个芯片验证工程师来说，仿真工具、验证环境、验证流程就是必备的生产力工具。Lynda想全程参与芯片研发业务，倒不怕从头开始，只不过没想到连这些必备品都能 “三无”。

当一家互联网公司投身半导体时，工具的欠缺还不是最紧要的。“造芯”不仅是业务的简单延伸，它往往意味着更复杂的产业链、更耗时的人才沉淀、以及更迥异的生态文化和技术理念。

比如芯片研发不像软件开发尚可后期不断改bug，设计问题没被前期验证发现，一旦流片就只能沦为一块“砖头”。而Lynda所担任的验证工程师，就是防止前期努力打水漂的守门员。

这个岗位的重要性不言而喻，设计工程师与验证工程师的比例在很多芯片公司会达到1：3。但Lynda入职后环顾四周，发现不仅自己只有一个并肩作战的同事，连验证的代码也一行都没有。

这时候，Lynda才开始明白Henry口中的“从零开始”意味着什么，以及她面临着怎样一场艰难的战役。

01

雄关如铁，出师未捷

在腾讯云副总裁、云架构平台部总经理谢明看来，“从零开始”的背后还有更多的曲折故事。

谢明所在的云架构平台部，站在腾讯各类前端应用的身后，是腾讯海量业务数据冲刷的前线，有效支撑了QQ、邮箱、微信、微云、流媒体视频等一个又一个的国民级应用。

2013年，QQ相册已经发展成腾讯最大的一个存储类业务。让用户访问相册的速度更快、体验更顺滑，成了一个很急迫的需求。转化成相应的技术问题，就是图片能否更快地转码？能否在不损画质的情况下压缩？能否以更低的成本存储？

他们反复地追问。

团队深刻地明白底层技术创新对上层应用的放大价值。软件架构上固然要永远不停歇地进行自我超越，但他们敏锐地察觉到，只有在硬件上也作出创新，才能实现更深层次的突破。

问题是：一个做软件出身的团队，怎么去做硬件？

一圈研究之后，他们决定先拿FPGA（可编程阵列逻辑）试水。跟我们平时电脑和手机里的通用芯片相比，FPGA是一种专用集成电路（ASIC），能够实现灵活的“半定制”开发。

FPGA相比起芯片容错率高，但在吞吐率、延迟、功耗和灵活性等维度上都很平衡。尤其是在处理海量数据时，FPGA相比GPU具有超低延时的显著优势，很适合用在特定的业务场景。

事实验证了这种判断。2015年，团队集中力量研发的图片编码FPGA，取得了比CPU编码和软件编码更高的压缩率和更低的延时，也帮助QQ相册很大程度上降低了存储成本。他们看到了在FPGA方向 探索 和深入的可能性。

2016年前后，由Alpha Go引爆的AI热潮更把FPGA拉入了主流视野。团队通过FPGA对深度学习模型的CNN算法进行加速后，处理性能达到通用CPU的4倍，而单位成本仅为1/3。

FPGA效果虽好，但技术门槛比较高，“如果把FPGA云化，是不是一个能够扩大应用的解决路径？”

带着这样的期待，2017年1月20日，腾讯云推出了国内首款FPGA云服务器，希望以云计算的方式，将FPGA能力推广到更多企业。

从效果上来说，在FPGA云服务器上进行FPGA硬件编程的企业，确实能将性能提升至通用CPU服务器的30倍以上，而只需支付相当于通用CPU约40%的费用。以一家著名的基因检测公司为例，传统用CPU需要检测一周的基因序列，FPGA可以压缩到数小时完成。

然而云化后的FPGA，没能如预期般迅速席卷整个行业。

一方面，FPGA毕竟是一种“半定制”的电路，许多企业还是无法独立胜任FPGA开发，需要更加上层的服务；另一方面，通用芯片成本的迅速下降，也让FPGA的性价比优势逐渐丧失。

云端商业化的受挫泼来一盆冷水，把团队的热情从巅峰一下子打到了谷底，同时也把两个问题赤裸裸地抛到整个团队的眼前：FPGA对业务的价值究竟有多大？FPGA还能继续做吗？

受此打击，团队在2018年也近乎分崩离析，人员开始集中式地离开。腾讯在“造芯”上的第一次 探索 ，画上了一个遗憾的逗号。

02

柳暗花明，“蓬莱”问世

在FPGA云服务器受挫后，腾讯需要重新思考硬件之路要怎么走下去。

在团队几乎解散的2018年，中国芯片行业迎来暖春：中美贸易摩擦给全民普及了芯片的重要性，科创板的设立为半导体企业上市开启大门，而国家资金的进场更是让大江南北一片热火朝天。

但是，对于互联网公司来说，做芯片跟做云计算、数据库、存储系统等一样，需要有具体的业务场景支撑，不能“为了做而做”。在经历过一场不算成功的 探索 后，腾讯要等待下一个真实需求带来的机会。

时间进入2019年。那是人工智能规模化应用的元年，内外部业务都提出了对AI芯片的强烈诉求。AI芯片，要不要做？

这个问题被提出来的时候，腾讯的管理层有过反对的声音，担心技术人员只是头脑发热，只是为了追逐热点。但同时，管理层也给了足够的灰度，没有明令禁止小团队级别的 探索 。

以小规模、低成本、特定应用场景的方式先行试水，成了大家的共识。

云架构平台部将第一款芯片敲定AI推理方向，取名“蓬莱”，希望这款芯片能像中国古代神话里的海外仙山一样，稳固地立于汹涌波涛之上。

这支硬件突围小分队，也被正式命名为“蓬莱实验室”。

有了FPGA 探索 时积攒的经验，蓬莱实验室对硬件编程语言已经相当熟练，也在标准接口、总线等方面积累了一些平台化的设计。然而，两者的研发要求，不可同日而语。

如果说做FPGA是搭现成的积木，那么做芯片就是直接从伐木开始来着手来制造积木。FPGA出了问题可以重新编程，而芯片只有一次流片机会，一旦出错，所有的努力便付诸东流。

此外， FPGA的资源是现成固定的，芯片的资源却是由自己定义的。一个字，就是要“抠”：用最小的资源做最大的事。

芯片架构工程师Rick用“装修”改“重建”来形容整个蓬莱项目。一开始，团队以为能把之前FPGA的技术较为简单地转成芯片。做着做着发现，以为终归只是以为——FPGA架构在芯片中能直接复用的并不多，团队只能把原来的架构整个拆掉，重写的代码量高达85%。

像DDR存储器这样的重中之重，芯片厂商通常会有专门的验证人员负责，而刚起步的蓬莱实验室没这个条件，只能靠抢时间把功课补回来。Lynda后来回忆道：“我恨不得一天有48个小时”。

2020年1月，蓬莱芯片流片完成，被合作方快递到深圳。新冠疫情刚刚在全国范围内暴发，公司已经开启集体远程办公。

项目负责人Henry戴着手套取到快递，用酒精仔细消毒后，带到空空荡荡的办公楼，大开着窗户和风扇，在一片消毒水味中，他和几个同事一起开始了至关重要的点亮 *** 作。

所谓点亮，就是给芯片上电，首先看有没有短路冒烟，接着就是测试一些基本功能。是芯片还是“砖头”，成败在此一举。

结果，芯片的时钟频率一直没出来。要知道，时钟频率是芯片的“节拍器”，没有时钟频率，芯片的不同模块等于没对好表，就无法协同工作。

是不是这块芯片的问题？实验人员换了一块芯片，依然没有信号输出。

再换一块，还是没有。现场鸦雀无声。

实验人员已经不敢动手了。有人忍不住开玩笑，是不是该回家改简历了。

但除了沮丧，大家心里更多的是疑惑。因为项目虽然人少、资源少，近乎是白手起家，但蓬莱团队从设计人员到验证人员都有信心说：每一步都做好了。到底是哪里不对呢？

在无比凝重的气氛中，他们继续放板、上电、读取信号……

第四块芯片，亮了。剩下的所有芯片，也都没问题。

真相其实很简单。28纳米工艺的芯片不良率只有3%，但偏偏随机测试的前三片都是坏片，小概率事件就恰好让他们全赶上了。这让他们把“生一胎”的紧张情绪，体验到十足。

在虚惊一场后的拍手相庆中，腾讯第一款芯片，宣告问世。

03

更上一层，“紫霄”凌云

量产后的蓬莱芯片，实战表现也不负众望，助力腾讯推出中国第一台获准进入医院临床应用的智能显微镜，实现自动识别医学图像、统计细胞数目并直接显示在视野上，性能表现完全符合设计要求。

这一扫当年FPGA云服务器项目的阴霾，说明在制造造出直面应用、性能卓越的芯片，这条路，腾讯走得通。

终端芯片蓬莱的问世，只是完成了从0到1的任务。团队已经迫不及待向要从1到N，向着大规模云端芯片进军。蓬莱实验室负责人Alex将大芯片申请立项戏称为“A轮融资”。

初试锋芒之后，团队需要向公司说明，为什么需要用更大的投入去做大规模芯片？在短期和长期能否保持领先性？如何与内外部业务结合创造价值？

腾讯这次面临的决策，要容易做得多。

首先是蓬莱实验室的成熟。通过一边行军一边成长，蓬莱实验室完成了一次次蜕变，建立起完整、严谨、规范的芯片研发体系和流程。这已经是一支具备硬核气场的“正规军”。

更重要的是，团队证明了腾讯做芯片的优势和站位。

谢明解释说，从行业来看，做芯片除了要考虑技术和工艺，最大的难点在于对芯片的“定义”。传统芯片厂商的优势在于前者，但芯片做出来之后再去匹配需求，在很多场景下真实性能是损失的。Google、腾讯这类 科技 企业的优势在于自身就是需求方，对需求的理解和洞察最深刻、最透彻。

方向没有问题，技术和工艺也没问题，腾讯高级执行副总裁、TEG（技术工程事业部）总裁卢山给予了全面支持，并通过总办争取到了更多的headcount和资金。

有了公司战略的支持，团队志气满满奔赴更大的战场。蓬莱实验室副总监Austin决定兵分两路，在AI推理和视频编解码上并行推进。

AI小分队继续做蓬莱的2.0版“紫霄”。这是《封神演义》里鸿钧老祖所居宫殿的名字。在稳固的仙山上牢筑“紫霄”，代表了新的野心：

这次，他们将目标直接定为业界第一。

紫霄所有的架构都围绕着有效算力去做。团队优化片上缓存设计，并摒弃竞品常用的GDDR6内存，采用先进的2.5D封装技术，把HBM2e内存与AI芯片合封在一起，从而把内存带宽提升了近40%。

技术迭代一日千里。紫霄立项后，业内最高性能表现又被竞品刷新。虽然紫霄的设计性能相比这个最高表现还足够“安全”，但团队还打算继续加码。

经过研究，他们在芯片内部增加了计算机视觉CV加速以及视频编解码加速，可创新性地大幅减小AI芯片和x86 CPU之间的交互和等待。

即便因此而增加了两个复杂的自研模块，团队仍然在计划的6个月时间里完成了从架构确定到验证以及流片的全部流程。

2021年9月10日，紫霄顺利点亮。

在图片和视频处理、自然语言处理、搜索推荐等应用场景下，这款芯片打破了制约算力发挥的瓶颈点，最终在实际业务场景性能表现达到了业界标品的2倍。

04

独立自研，“沧海”一笑

AI小分队给自己芯片取名“紫霄”，而视频编解码则取名“沧海”，颇有海天相接之意。

不同于蓬莱和紫霄主打AI，沧海是一款视频转码芯片。如果说当年QQ相册图片的转码问题是蓬莱团队做硬件的最早契机，那视频编解码小分队在这个方向上的继续 探索 ，正是完成了一次对初心的呼应。

不同的是，“沧海”的应用场景已经远超当年的范畴。

当多媒体业务从图片时代进化到音视频直播时代，天量的4K/8K超高清的数字内容如潮水一般持续冲击着云计算基础设施。每增加一个比特的数据，都会带来相应的转码算力和CDN带宽成本。

这是一道直观而严峻的数学题，而沧海小分队的解题目标也非常清晰，那就是要做一款业界最强的视频转码芯片，把压缩率发挥到极致。

好在，腾讯丰富的多媒体应用场景，以及腾讯云覆盖的众多直播互动头部客户，为沧海的研发提供了得天独厚的分析和验证条件。

团队先是推出了沧海的核心自研模块——硬件视频编码器“瑶池”，并决定在沧海完成研发之前给瑶池一次大考。

这个大考就是2020年的MSU世界编解码大赛，该大赛由莫斯科国立大学（MSU）主办，十多年来一直是全球视频压缩领域最具影响力的顶级赛事，吸引了包括英特尔、英伟达、谷歌、华为、阿里和腾讯在内的国内外知名 科技 企业参与。

结果是，瑶池实现1080P@60Hz的视频实时编码，力压群雄获得了SSIM (结构相似性)、PSNR(峰值信噪比)和VMAF(视频多方法评估融合)等各项客观指标评测第一名，以及人眼主观评价第一的好成绩，相比第二名领先了一个身位。

经此硬仗，沧海在技术上得到了充分检阅。

2022年3月5日，Derick和他带领的视频编解码小分队收到流片回来的芯片“沧海”，又正逢深圳因疫情而全面远程办公。

他们申请特批进入空空荡荡的办公楼。这情景，和两年前点亮蓬莱时何其相似。

不曾想到，点亮蓬莱时的一波三折，同样重现。克服了一些调试中的意外，在一片欢呼中，腾讯的第三款芯片、同时也是完全自主研发的第一款芯片沧海成功点亮。

化沧海为一粟。沧海最终实现以更小的数据量、更小的带宽提供相同质量的视频，压缩率相比行业最佳表现还提高了30%以上。

从蓬莱到紫霄再到沧海，从28纳米工艺到12纳米工艺，从8个人发展到100多人，从仿真工具一无所有到“天箭验证平台”正式落成，从努力跟上合作伙伴的节奏到独立做完全SOC。

两只小分队胜利会师。蓬莱团队，完成了一场“芯”路进化。

05

“100G”时代，双木参天

躬身跳进造芯大潮的，不是只有云架构平台部。

在多媒体、AI处理积极求变的同时，底层的云服务器也面临着相似的问题：当软件优化带来的性能提升无法让产品拥有区别于竞品的明显竞争力时，如何让性能突破现有天花板？

2019年，腾讯迎来云计算业务上的里程碑——云服务器规模突破了100万。腾讯云副总裁、腾讯网络平台部总经理邹贤能敏锐地观察到，随着服务器接入带宽不断提升，服务器用于网络处理的CPU资源也越来越多。

能否以更低成本的方式来实现服务器网络处理，同时还提供更高的网络性能？腾讯的网络平台部也将目光投向了软硬协同与硬件加速。

面对这样“既要、又要”的挑战，邹贤能决定给服务器做个减法：“把网络数据处理的负担从CPU卸载出来”。

“智能网卡”的想法就这样诞生了。

所谓智能网卡，一方面像普通网卡一样肩负起服务器的对外网络访问，实现不同服务器和数据中心之间的网络互联。另一方面，它额外带有CPU/FPGA/内存等智能单元，能分担一部分服务器的虚拟化计算任务，实现服务器整体网络和存储性能的加速。

换句话说，网络平台部要做的事，是要在网卡里新装一个服务器。

一开始，团队希望找到一款现成的商用板卡降低工作量。

网卡硬件负责人Hayden牵头开展方案论证和调研，但商用芯片的加速引擎不支持私有协议成为当时直面的第一大挑战，也是最大的障碍。一些著名的网卡设备商听了腾讯的要求就摇头：

“现在网卡的功能很简单，你们这个要求太复杂了，很难实现的。”

还有些直白地质疑：“网卡数量这么多，可靠性要求高，你们自己搞得定吗？”

难道智能网卡项目刚起步就要流产？

邹贤能给团队指明了方向：“既然智能网卡是云数据中心追求极致性能与成本的关键部件，如果市面上没有满足腾讯需求的产品，那我们就自己造一个。”

方向明确之后，路线也很快清晰起来：先从基于FPGA自研智能网卡起步，再开展智能网卡芯片研发。

2020年9月，腾讯第一代基于FPGA的自研智能网卡正式上线，命名为“水杉”，寄寓着团队希望产品可以像这种珍稀乔木一样适应性强、快速生长。

疫情期间各种突发需求砸来，初生的水杉没有被挑战压弯。

Hayden回忆道，一个大客户本身采用了UDP音视频协议，在属性上是“不可靠”、允许丢包的，极大地依赖网络吞吐和稳定性，却要求高并发、高质量的音视频传输效果。

水杉智能网卡迎难而上，通过大幅提升服务器的网络性能，帮助该客户完成了24小时零丢包的极限压力测试，稳定上线运行，交出了一份漂亮的答卷。

水杉投入应用后，第二代智能网卡“银杉”的研发工作也紧锣密鼓地启动，并于2021年10月正式上线。这一代智能网卡的网络端口翻了一番，达到了2*100G。

在又一颗参天大树的支撑下，腾讯云对外推出了业界首款自研第六代100G云服务器。它的计算性能提升最大220%、存储性能最大提升100%。单节点接入网络带宽相比上一代最大提升4倍，延时下降50%。

“两棵树”在网络硬件卸载上取得的巨大收益，令团队兴奋不已。

当FPGA路线逐渐逼近性能和功耗的瓶颈，网络平台部决定再一次把主动权掌握在自己手里。腾讯的第四款芯片，也是首款智能网卡芯片应运而生，它也有一个 “仙气十足”的名字——“玄灵”。

06

“玄灵”乍现，芯事未完

按照计划，这款7纳米工艺的芯片将在2022年底流片。

Hayden受命快速组建起了玄灵芯片研发团队，不断挑战多个“mission impossible”。

从性能指标来看，玄灵支持设备数量将提升到10K以上，相对商业芯片提升6倍。同时，它的性能相对商业芯片也可提升4倍，通过将原来运行在主机CPU上的虚拟化、网络/存储IO等功能卸载到芯片，可实现主机CPU的0占用。

这颗短小精悍的芯片，充分诠释了面向未来极致性能的“玄”，与面向各类业务需求灵活加速的“灵”。

目前，玄灵项目正在紧锣密鼓地进行智能网卡流片前的验证和测试，打造腾讯云下一代高性能网络基础设施；

蓬莱实验室的AI推理芯片紫霄和视频转码芯片沧海则将量产，与腾讯业务深度融合应用；

还有一些新的芯片项目也在酝酿成长，继续 探索 有需要的技术方向，丰富这一本“山海经”。

腾讯海量业务面临的全新挑战，以及云计算高速发展的必然要求，“倒逼”腾讯走上了这条造芯之路。这些从业务需求出发的芯片，必定会深入现实应用来证明自身的价值。

“我们不是无中生有、拍脑袋要去做芯片。我们一开始就知道，腾讯的需求足够大，足够我们去做这件事。”卢山说道。

从2010年起，腾讯就开始以云服务的方式对外开放自身的数字技术与连接能力，奔赴这场产业数字化转型升级的时代大潮。躬身入局，腾讯看到深度的数实融合正在引领全真互联的技术趋势。

而在腾讯之外，中国的 科技 公司们正在向创新的深水区挺进，突破瓶颈的努力显得愈发重要。无论是数实融合还是上游创新，硬 科技 的海面上一片百舸争流，它们都在 历史 的浪潮奋楫中流。

在这场大潮中置身事内，腾讯的芯事必然在星辰大海中得到回响。

---