本文内容整理自腾讯专家研究员 & 微信视频技术负责人谷沉沉在 2017 ArchSummit 全球架构师峰会上的技术分享。
2012 年 7 月，微信 4.2 版本首次加入了实时音视频聊天功能，如今已发展了 5 年，在面对亿级微信用户复杂多变的网络和设备环境，微信多媒体团队在每个技术细节上不断地深耕细作，为微信用户提供了高质量的视频通话。
今年腾讯全球合作伙伴大会上发布的《2017 微信数据报告》显示，到 2017 年 9 月，微信日成功通话次数 2.05 亿次，月人均通话时长 139 分钟，月人均通话次数 19 次。无论是通话次数还是通话时长都比去年增加了一倍多，这个增长速度远远高于微信用户量的增长，这与微信多媒体团队在音视频技术上的努力是分不开的。
本文将为大家介绍微信实时音视频聊天在不同发展阶段的各个关键视频技术环节采用的方案，同时分享在实时音视频聊天中的视频编码器研发的方法和经验。
在本次正式技术分享前，谷沉沉作为受访嘉宾，接受了InfoQ的技术专访，技术专访内容请见《专访微信视频技术负责人：微信实时视频聊天技术的演进》。
（本文同步发布于：http://www.52im.net/thread-1311-1-1.html）
学习交流：
- 即时通讯开发交流群：320837163[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
谷沉沉：腾讯专家研究员 & 微信视频技术负责人。
2007 年硕士毕业于哈尔滨工业大学，在校课题研究期间参与过 AVS、H.264SVC 等视频编解码标准技术研究。加入腾讯后也一直从事视频图像相关的技术研发工作，先后主导过 QQ、微信、手机 QQ 视频通话、腾讯视频等产品的视频技术研发，目前主要负责微信视频通话、朋友圈视频图片等业务相关的视频图像技术研发和团队技术管理。
拥有丰富的视频技术研究与应用实战经验，在国际视频领域知名学术会议刊物上发表多篇论文，数十项视频技术领域的发明专利在国内外获得授权，其中两件独立发明的专利荣获中国专利奖。
与很多互联网视频应用类似，互联网视频通话的应用目标也是希望用尽可能低的成本使视频更加清晰与流畅。
上图右边互联网视频应用的代价成本包含两个维度：
一是带宽成本：包括客户端用户的流量成本，以及服务器端带宽成本；
二是计算开销：表现在服务器端的设备投入量，以及客户端的 CPU 占用、耗电量等，而对于性能较差的客户端设备，控制客户端的计算资源还可以保障这些设备也能支持基础质量的视频通话。
上图中谷沉沉列举了四类互联网视频应用，其中视频通话应用相对于短视频分享、流媒体直播和媒体存储来说有三个特殊的挑战：
第一：由于微信视频通话集中在移动端，这就要求系统的计算复杂度尽可能低；
第二：由于视频通话是高度实时的应用，决定了视频数据一般采用不可靠传输，这就要求视频传输具有一定的鲁棒性，比如抗丢包的特性，另外，由于没有缓冲机制，视频发送码率要尽可能平稳；
第三：由于很多用户在 3G、4G 等移动网络下使用，对流量比较敏感，所以视频通话带宽占用要尽可能低。
最左边三点是微信视频通话作为海量级用户产品具有的特殊难点：
1）用户的网络状况和设备性能差异巨大，所以微信视频通话要适应不同的网络和设备；
2）由于用户版本更新存在一定的周期，这就需要考虑新技术对旧版本的兼容性；
3）另外，海量并发用户对服务器端造成的带宽成本压力也是必须要考虑的。
所以，互联网视频通话是各种互联网视频应用中约束条件最多、最苛刻，也是实现难度较大的一种互联网视频应用。
据谷沉沉透露，现在微信视频通话是基于微信多媒体团队自研的多媒体应用综合引擎——WAVE (Wechat Audio&Video Engine)。该引擎的底层——内核层是由传输、视频、音频三大类跨平台技术构成的。在此之上，针对不同应用类型的特点做了一些接口封装和应用逻辑设计，形成应用层，目前支持三类不同的应用：第一类是实时通话应用，目前用于微信的点对点和多人视频通话。第二类是多格式的图片处理，主要用在微信朋友圈、公众平台以及表情等图片的压缩和处理上。第三类是音视频文件压缩，应用于朋友圈视频、语音和视频消息的压缩和处理等。
经过多年的技术积累，WAVE 引擎支持了每天数亿的视频通话、数十亿的视频播放、数千亿的图片查看，所以整个引擎在压缩效率、计算速度、音视频质量等方面的性能都经过了微信亿万用户的考验，是业界比较领先的多媒体引擎。
谷沉沉表示他们团队现在还在不断提高引擎的处理速度、压缩效率等性能，希望能用最合理的成本为广大用户提供最好的多媒体体验。
下图是基于 WAVE 引擎的微信视频通话系统，包含视频、音频、传输三大类技术，分布在设备层、引擎层、服务器端三个层面。标红的部分是视频引擎涉及的技术。
下图是 WAVE 微信视频引擎的框图，在发送端，摄像头采集的原始视频数据，一路直接在本地小窗口渲染，另一路先经过视频前处理，再进行视频编码，之后对编码生成的码流进行容错保护，最后发送到网络上。相应地，在接收端，对收到的码流先进行错误恢复，对正确恢复的数据进行视频解码，而后通过后处理增强提升视频质量，最后经过播放控制流畅地显示在接收端屏幕主窗口上。
其中 QoS 的反馈模块会收集接收视频的质量、网络状况等信息，通过服务器处理反馈到发送端，发送端再根据这些信息选择合适的视频编码的参数，这样就能实时适应不同的网络状况。目前，很多网络适配算法都是在 QoS 服务器上执行的，这样，如果新算法发布后发现问题，不用等到下一个客户端版本的发布，就可以快速地在服务器端进行修改控制，加快算法的迭代进度。
上图列出了视频引擎中最关键的六大模块的技术，其中最核心的是决定整个引擎基础性能的视频编解码模块，与之密切相关的有前后处理、容错保护、网络适配模块，还有设备层的采集与显示，以及对海量用户通话情况的评价和运营体系，这六个模块技术协同配合，任何一个模块的短板都会影响整体视频通话质量。
在微信实时音视频聊天版本发展的不同时期，这些技术模块的发展也是各有侧重，整体上大致经历了三个阶段：
第一阶段是基础框架的搭建和性能优化：
2010-2012 年，第一个微信视频通话发布前后的这段时间，当时大部分主流移动设备 CPU 主频只有单核 1GHz，为了在这样的设备上能流畅运行视频通话，微信多媒体团队在视频编解码速度优化上下了很大的功夫，当时优化后的编解码速度在同等压缩效率下已经达到了业界领先水平；在采集显示环节也采用了快速、高质量的方案，并做了大量代码流程优化以提高处理速度，如减少内存的拷贝，优化格式转换流程等；由于当时客户端计算能力是整个视频通话的瓶颈，视频帧率、码率较低，发送数据量对于大部分网络不会造成太大压力，所以第一阶段的容错保护策略非常简单，只对关键帧做保护。经过这些基础性能的优化，第一个微信视频通话版本跟业界同类产品相比，同等带宽下的视频清晰度和流畅度都是非常不错的。
第二阶段是随着移动设备硬件性能的逐渐提升：
一些性能较好的移动设备可以支持更高帧率的视频通话，发送码率也随之增大，于是网络适配策略就成为这一阶段的研发重点，由于实验模拟网络环境与海量用户真实的网络环境总是存在差异，所以很多网络适配算法在经过模拟环境下的验证后，还必须进行线上灰度测试，通常会随机抽取大量样本做算法的对照实验，如果在大规模样本上新算法的各项技术指标均优于现网算法，才会逐步放开到所有的通话。在这个灰度测试过程中，海量用户通话质量的评价运营体系也逐步建立和完善。
第三阶段是在近两年，移动设备性能大幅度地提升：
很多 4 核 8 核手机的性能甚至比早些年的 PC 机都要好，设备的计算性能已经可以支撑更高复杂度的计算，因此微信多媒体团队开始研发视频前后处理技术以提高主观质量，同时在视频编解码上也加入了一些高复杂度、高压缩效率的算法，使视频通话在同等带宽下可以达到更高的视频质量。
由于演讲时间所限，将选择其中视频编解码、前后处理和容错保护三个模块进行重点技术分析。
在互联网视频应用中，视频编解码的核心指标概括起来一般有三个：
编码效率；
编解码速度；
传输适应性。
而这些指标之间是相互制约的，编码效率的提升往往是以牺牲编码速度为代价，传输适应性也会影响编码效率，比如容错保护时增加冗余会导致编码效率下降。所以一个好的视频编解码器需要在这些指标之间找到合理的平衡点。
这三个指标在视频通话中具体需要关注哪些方面呢？
首先，在编码效率上：
1）微信视频通话的场景非常多样，除了类似传统视频会议那样整体内容比较静止的场景外，还有很多运动剧烈的场景。可能很多人认为微信视频聊天通常都是手持手机摄像头对着人脸，应该都属于比较静止的视频场景，但在摄像头距离人脸较近时，人脸在视频画面中占据了较大部分，这样人脸的一点轻微运动对于整个视频来说已经是属于运动比较剧烈的内容场景，同时手持设备不稳定时还会造成视频画面的抖动，使运动更加复杂，因此微信视频通话中的编码算法必须适应多种不同的场景；
2）历史版本互通兼容性，新的编码技术必须要考虑旧版本的解码兼容性，所以一旦编解码格式确定就不能频繁更新，只有当技术积累到一定程度，压缩效率有突破性的提升，才会考虑升级替换；
3）主观质量是“王道”，对互联网应用来说，普通用户不会关注 PSNR 等客观质量指标，只会用眼睛来看，所以任何的客观数据都只是技术上一种便捷的衡量方式，最终的衡量标准还是人眼的主观感受。
其次，在编解码速度方面：
编解码算法复杂度和实现优化程度都是影响编码速度的重要因素。实现优化包括软件的快速算法和代码级优化，也包括硬件加速。随着一代又一代的视频编码标准的发展，编码效率的提升往往伴随着算法复杂度的增加，CPU 难以支撑高复杂度的软件编解码计算，如果硬件视频编解码各方面性能可以满足视频通话的需求，利用硬件来加速视频编解码就可以极大地缓解 CPU 计算资源压力。此外，还要考虑帧级复杂度的均匀性，因为视频通话能支持的最高帧率是由序列中编码最慢的帧的时间消耗决定的。
第三，在传输适应性上：
要求视频码流的码率尽可能平稳，更严格地，还要控制帧级瞬时数据量冲击，以减少瞬时数据量冲击造成网络拥塞而出现丢包、延时等问题。此外，视频码流还需要具有一定的抗丢包能力。
根据多年的工作经验，我们总结了打造一个优秀可靠的互联网视频应用软件 Codec 的四个阶段。
针对其中第三、第四阶段的优化，用两个微信多媒体团队实战优化过程中的案例进行具体说明：
第一阶段是格式的确立：主要是根据应用的计算复杂度要求选择合适的编码标准格式，或者开发私有格式，这一阶段主要考虑编码效率，评价方式类似标准组织的通用测试条件。
第二阶段是实现优化：主要是通过代码优化和快速算法优化等提高编解码速度，同时控制编码效率损失，在满足应用要求的条件下，达到编码效率和编解码速度的合理平衡。
第三阶段是应用定制：针对特定的应用场景需求做一些定制的研发，达到合入产品预发布的要求。比如微信视频通话中的码率平稳性要求，以及编码参数切换支持等，都是在这个阶段通过码率控制算法优化来实现的。
码率控制的难点是平衡码率平稳性和压缩效率、质量平稳性。虽然学术上有很多码率控制的研究，但实际工程应用中还是有很多问题需要考虑，如码率控制的时间单位，极低帧率、极小 I 帧间隔下的码率控制，单帧瞬时冲击等。
上图的第一张设置目标码率 360kbps 的每秒数据量波动图中，紫色线是微信自研视频编解码器的码率波动情况，可以看出每秒的码率基本都稳定在 360kb 左右，而蓝色线表示的同等编码效率下 x264 码率波动情况，在一些运动比较剧烈的场景，码率会上升到 420kb，明显高于目标码率，这对我们实时视频通话应用就会有很大的冲击。
虽然第一张图中微信自研视频编解码器的每秒数据量波动已经非常平稳了，但第二张图中红色线表示的半秒数据量波动曲线还是呈锯齿状，这在传输中依然会对网络产生一定的冲击，为了进一步提升码率平稳性，微信多媒体团队又进行了第二轮更加严格的码率控制优化，可以看出绿线所示的现网微信视频通话版本半秒数据量波动明显比第二轮优化前的红线平稳。
第四个阶段是打磨稳定，虽然前面每个阶段都会对编解码器进行编解码匹配、编解码各项指标性能等编解码器离线测试验证，但在合入产品应用后，尤其是在海量用户实际应用环境中，还是会出现一些编解码器离线测试时发现不了的问题，如主观质量的缺陷问题，需要逐一分析尽可能优化主观质量，以及当解码器接收到不能正常解码的“脏”数据时，需要加强解码器的鲁棒性保护，及时终止解码防止 crash 等。
这里分享了在微信实时音视频聊天研发过程中减轻块效应的两个优化方向：
1）一个优化方向是码率分配微调，包含帧级和帧内两个方面：
帧级码率分配微调是针对码率平稳性优化造成运动剧烈场景下视频质量损伤明显的问题。因此在完成码率控制算法之后需要根据主观质量情况对码率分配做一些微调，适当增加运动剧烈场景下码率分配以提高质量；帧内率分配微调是指，由于人眼对平坦区域更加敏感，所以也会多为平坦区域多分配一些码率。在上面这个视频中，左面是优化之前，右面是优化之后，在运动剧烈场景中，如挥手的时候，手的部位较平坦区域块效应明显减轻。
2）另一个优化方向是编码模式的微调，这里举两个例子：
2.1）一是关于 skip 模式的判定：
上图左下角解码视频截图中脸部标红圈的地方出现比较明显的块效应问题，经过分析发现这个视频中相邻的这两帧在这个位置上内容相似，编码过程中基于率失真最优原则的模式选择结果是采用 skip 模式编码，简单说就是直接拷贝前一帧中相应的像素块，虽然在客观编码效率上是当前块最优的编码模式，但主观质量上块效应比较明显，微信多媒体团队对 skip 模式的判断条件做了一些微调，将这种情况改用 inter 模式编码，多留一些残差信息，虽然这个位置“花费”的比特数比 skip 模式多一点，但失真度也会低一些，图中右面经过调整之后这个位置基本看不出块效应。
2.2）另一种编码模式的微调是 intra 和 inter 模式的选择：
当 intra 和 inter 模式编码的率失真代价比较接近，采用哪种模式编码对客观编码效率影响很小。但是在主观质量上，有时候 inter 模式的残差较小，量化之后一部分小系数的丢失也容易造成块效应，这个时候针对这些场景利用一些辅助的统计信息，将这种场景判定为 intra 模式编码就能解决这类块效应问题。
前后处理的增强效果毋庸置疑，但在很多场景下“副作用”也比较大，比如去噪容易造成细节模糊甚至缺失，锐化可能带来锯齿效应……
因此研究前后处理算法的关键是要消除“副作用”，微信多媒体团队就是按照“宁缺毋滥”的原则，即每次前后处理算法的更新可以只对部分场景增强，增强的幅度也可以较小，但必须保证不会出现质量变差的场景。在算法研究阶段需要设计好场景自适应策略，对于算法无法完全解决的情况，再辅以运营策略，比如“白名单、黑名单”机制，对特定型号设备开启或关闭相应的算法等。
案例分享：光照增强
光照增强问题的发现来源于微信多媒体团队的一次视频通话测试体验，在晚上室内日光灯环境下，不同手机摄像头采集的视频质量差异较大，有些手机的采集视频与真实环境光照基本一致，而有些手机采集的视频就偏暗，甚至连人脸都无法看清。
针对这种情况，微信多媒体团队自主研究了一种低照度视频增强方法：
先通过对单帧平均亮度和最大、最小亮度等信息的分析和统计，推导出单帧的亮度增强和对比度增强的自适应约束；
为避免视频连续播放出现亮度闪烁，算法还考虑了前后帧亮度变化的一致性约束；
最后对三个方面的约束做联合优化求解，由于优化项中只包含二次项，再进行快速算法实现优化，求解过程计算复杂度较低，因此整个光照增强技术可以在视频通话中实时处理。
上图左上角子图 (a) 为低光照的输入源视频截图，(f) 为微信自研光照增强算法处理后的视频截图，增强后可见脸部更多细节和背景环境的纹理，而从其余几个现有视频图像增强对照算法处理后的截图中，可以看出存在不同程度的颜色异常或增强效果不明显等问题。
这项实用的研究成果在应用于微信视频通话有效提升视频质量的同时，也得到了学术界的高度认可。该算法相关的论文已发表在国际视频领域知名会议 ISCAS2017 上，并受邀在大会上宣讲，也是该次会议上仅有 5% 来自工业界的论文之一。感兴趣的读者可参考《Low-Lighting Video Enhancement Using Constrained Spatial-Temporal Model for Real-Time Mobile Communication》, IEEE ISCAS, pp：595-598, 2017。
容错保护往往通过增加冗余来实现，而视频编码又是通过降低冗余来提高压缩效率，所以容错保护的关键是要做到压缩效率和容错能力的平衡。
主要有信源容错和信道容错两类方法：
1）信源容错可以通过改变参考关系：
比如上图里 IPPP 这样依次参考的结构，如果 P4 这帧丢失了，后面从 P5 开始所有帧都无法正常解码，在视频通话中就表现为卡住。但如果改变参考关系，让 P5 参考 P3，这样 P4 虽然丢失了，但是 P5 和后面的帧都还可以正常解码，这就是一种抗丢包能力。由于 P5 的参考帧距离变远了，相关性比 P5 和 P4 之间的相关性弱，P5 的数据量就会增大，压缩效率就会降低，这就是这种容错方式所带来的时域冗余代价。我们需要在容错能力和冗余代价上取得较好的平衡，在应用中也可以根据网络状况选择合适的冗余能力。
2）信道容错的方法有信源容错可以通过改变参考关系来提高在丢包环境下的视频解码正确率：
如上图中 IPPP 参考帧结构，若 P4 帧丢失了，其后从 P5 开始的所有帧都无法正常解码，在视频通话中就表现为卡住。但如果改变参考关系，使 P5 参考 P3，这样，P4 的丢失就不影响 P5 及其后续帧的正常解码。但由于此时 P5 的参考帧距离变大，可能造成 P5 的帧间预测准确性下降，导致 P5 编码数据量增大，压缩效率降低，这就是这种容错方式所带来的时域冗余代价。因此需要在容错能力和冗余代价上取得较好的平衡，在应用中也可以根据网络状况选择合适的容错能力。
在信道容错方面，有分组异或、RS 编码等 FEC 前向纠错技术。可以根据每一帧的重要性等级增加不同的冗余保护，上图中红色越深的帧表示重要性越高，它的丢失会造成更多帧解码失败，可以对这些越重要的帧增加越多的冗余保护。另外，对低延时网络，如果遇到丢包导致解码失败，可以向发送端主动请求编码 I 帧，避免长时间的卡顿。
谈到未来，谷沉沉表示互联网时代业务和技术日新月异，在不太远的未来几年内，视频技术的发展方向大致有三类：
1）基础技术的突破，如 H.266、AVS3、AV1 等下一代标准，以及最近的热点研究方向——基于深度学习的视频图像压缩，压缩效率将进一步提高；
2）现有视频产品的体验提升，继续向着高质量、低带宽 / 存储空间、低功耗的方向发展；
3）新的产品形态不断出现，比如 3D、VR 甚至光场等沉浸式的视频通话。
未来，微信多媒体团队将继续坚持以专业、专注的精神，研发实用的多媒体技术，也欢迎对视频图像技术感兴趣的优秀人才加入或开展技术研究合作，一起来不断提升数亿用户的微信视频通话等各类视频图像相关业务体验！
[1] 有关QQ、微信的技术文章：
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯团队分享 ：一次手Q聊天界面中图片显示bug的追踪过程分享》
《微信团队分享：微信Android版小视频编码填过的那些坑》
《微信团队披露：微信界面卡死超级bug“15。。。。”的来龙去脉》
《月活8.89亿的超级IM微信是如何进行Android端兼容测试的》
《微信客户端团队负责人技术访谈：如何着手客户端性能监控和优化》
《微信团队原创分享：Android版微信的臃肿之困与模块化实践之路》
《微信团队原创分享：微信客户端SQLite数据库损坏修复实践》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《开源libco库：单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]》
《微信新一代通信安全解决方案：基于TLS1.3的MMTLS详解》
《微信团队原创分享：Android版微信后台保活实战分享(进程保活篇)》
《微信团队原创分享：Android版微信后台保活实战分享(网络保活篇)》
《Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]》
《微信团队原创分享：Android版微信从300KB到30MB的技术演进》
《微信技术总监谈架构：微信之道——大道至简(PPT讲稿) [附件下载]》
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《微信异步化改造实践：8亿月活、单机千万连接背后的后台解决方案》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
《微信团队原创分享：Android内存泄漏监控和优化技巧总结》
《微信团队原创Android资源混淆工具：AndResGuard [有源码]》
《移动端IM实践：Android版微信如何大幅提升交互性能（一）》
《移动端IM实践：Android版微信如何大幅提升交互性能（二）》
《移动端IM实践：WhatsApp、Line、微信的心跳策略分析》
《移动端IM实践：谷歌消息推送服务(GCM)研究（来自微信）》
《信鸽团队原创：一起走过 iOS10 上消息推送(APNS)的坑》
>> 更多同类文章 ……
[2] 有关QQ、微信的技术故事：
《2017微信数据报告：日活跃用户达9亿、日发消息380亿条》
《技术往事：创业初期的腾讯——16年前的冬天，谁动了马化腾的代码》
《技术往事：史上最全QQ图标变迁过程，追寻IM巨人的演进历史》
《开发往事：深度讲述2010到2015，微信一路风雨的背后》
《开发往事：记录微信3.0版背后的故事（距微信1.0发布9个月时）》
>> 更多同类文章 ……
[1] 开源实时音视频技术WebRTC的文章：
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
>> 更多同类文章 ……
[2] 实时音视频开发的其它精华资料：
《即时通讯音视频开发（五）：认识主流视频编码技术H.264》
《即时通讯音视频开发（九）：实时语音通讯的回音及回音消除概述》
《即时通讯音视频开发（十）：实时语音通讯的回音消除技术详解》
《即时通讯音视频开发（十一）：实时语音通讯丢包补偿技术详解》
《即时通讯音视频开发（十三）：实时视频编码H.264的特点与优势》
《即时通讯音视频开发（十五）：聊聊P2P与实时音视频的应用情况》
《即时通讯音视频开发（十六）：移动端实时音视频开发的几个建议》
《即时通讯音视频开发（十七）：视频编码H.264、VP8的前世今生》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1311-1-1.html）
微信关注我们
转载内容版权归作者及来源网站所有！
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。
马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273