实时音视频聊天中超低延迟架构的思考与技术实践
一、前言
从直播在线上抓娃娃，不断变化的是玩法的创新，始终不变的是对超低延迟的苛求。实时架构是超低延迟的基石，如何在信源编码、信道编码和实时传输整个链条来构建实时架构？在实时架构的基础之上，若是经过优化采集、编码、传输、解码和渲染中的关键环节来下降延迟？本文将会介绍即构在这方面的思考与实践。php
学习交流：html
- 即时通信开发交流群：320837163 [推荐]web
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》算法
（本文同步发布于：http://www.52im.net/thread-1465-1-1.html）跨域
二、关于做者
关旭：即构科技音视频引擎核心专家，硕士毕业于南开大学数学系，前后就任于中兴通信、腾讯等公司负责音视频相关的研发工做，在实时音视频技术上有多年积累，当前在即构科技主要负责音视频引擎核心开发。服务器
三、相关文章
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》微信
《移动端实时视频直播技术实践：如何作到实时秒开、流畅不卡》websocket
《首次披露：快手是如何作到百万观众同场看直播仍能秒开且不卡顿的？》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
四、从直播到线上抓娃娃
图 1 展现了实时音视频两种不一样的应用场景——连麦互动直播和线上娃娃机。虽然这两种都是互动，可是对于实时音视频的要求却不一样。第一个实时连麦是语音视频流的互动，例如其中一个说了一句话，另一我的听到了，再回复一句话，这个实时性只是对语音视频流的实时性要求很高。而第二种线上抓娃娃则对信令的延迟提出了更高的要求，操纵者无需说话，看到的是娃娃机传回来的视频流结果。
若是考量互动直播是用实时音视频的延迟，那么线上抓娃娃则是用信令和视频流的延时。随着时代的发展，咱们对实时语音视频的定义会慢慢有一些不一样，未来可能还有更多的因素须要考虑。
图 2 是咱们互动直播的实时架构图，咱们把互动直播分为两部分，一个是主播侧，须要更低的延迟，另外一侧是普通观众，对延时不太敏感，但对流畅性敏感，中间经过一些旁路的服务把这两个集群（一个集群叫超低延迟集群，另一个集群叫围观集群）链接起来。
在超低延时部分，咱们提供的服务包括流状态更新、房间管理等，以及一些流媒体服务，主要起到分发的做用。咱们经过超低延迟服务器集群（和观众侧不太同样），提供实时分发的功能。
此外还提供了动态调度的服务，帮助咱们在现有的资源网络上找到更好的链路。后面的观众集群是另一个集群，把它们分开是出于一些业务方和咱们本身成本上的考虑，另外会提供存储、PCB 加速、分发的功能。
中间的旁路服务包括混流、转格式（主要是转码）、转协议等。为何要混流？举一个比较简单的例子：当主播一侧有 9 我的连麦，若是没有混流服务，观众端就会同时拉 9 路音视频，这样对带宽压力很大。
普通观众是经过围观服务器集群（延迟相对大的集群）去拉这些流的，这个集群的延迟可控性相对比较弱，有可能会出现这 9 路画面之间的不一样步现象，经过混流服务，观众拉的都是合成好的音视频流，就不会出现各路流之间的不一样步问题。
还有转格式转码的服务，前面集群提供的是很低延迟的服务，里面一些，好比说编码码流，不可以在传统的 CDN 网络分发，若是想在传统的 CDN 网络上分发，就要服务端的转码。还有就是转协议，由于前面提供一个更低延时的服务，后面要在 CDN 网络上分发，因此协议也须要转。
图 3 是线上娃娃机的 APP 版本的架构图，这里的是特点是线上娃娃机能够实时推两路视频流，上机玩家能够随时任意去切其中一路画面去看。这两路视频流首先经过咱们超低延时服务器集群，同时上机玩家也能够推一路流上去，能够给围观观众方看到这我的在抓娃娃时候的一些表情、反应、语言，增长一种互动性。此外，玩家须要经过手机远程操控娃娃机，所以还须要实时信令的分发。
接下来是娃娃机的 H5 架构图（图4）。在推流方面和 APP 版本没有太大的区别，娃娃机一侧仍是走的私有协议。不一样的地方是由于私有协议没有办法直接让 H5 拉到流，因此中间会加入一个媒体网关，做用是把咱们的私有协议翻译成 H5 能够识别的码流格式，而后 H5 端经过 websocket 方式把这路流拉下来，这里须要媒体网关作到超低延时的转换。
简单来看，这里的网关服务器只是作了一个分发服务，好像不会引入延时，实际上否则。
由于 websocket 拉的是 TCP 的流，可是咱们推的是 UDP 的，当视频帧很大的时候，一个帧数据就要切割成不少 UDP 包上行，服务器须要将这些 UDP 包攒起来，凑成一个完整的帧后才下发给 H5，这样才能保证不花屏，才能跑得通，因此这个攒包组帧的过程是会有延迟的。信令部分和 APP 部分基本是类似的。
五、实时架构的若干点思考
刚才介绍了实时音视频的两种场景，下面提出一点思考：
1）实时音视频有什么样的特征？
2）怎么样去架构一个实时音视频系统？
这是仁者见仁，智者见智的问题。你能够经过不少方式把这个系统架构起来，都会达到相对不错的效果。可是我认为，不管怎样，实时音视频都有绕不过以下几个点，只有把它们作好了，才可以在业界有更高的知名度、更好的技术储备。
第一是实时音视频是不能等的：
由于等了就不是实时音视频了。 不能等，这里会引入一个矛盾。既然不能等，例如你把实时音视频也看做一个消费模型来看，那是提早生产仍是按需生产？字面上理解很简单，确定是按需生产，须要的时候才生产，若是提早生产就是延时了。可是并非每个点都作成按需生产是合理的。
举一个例子，好比你要去播放一段音频，最好的作法是系统或者驱动告诉你，它须要数据了，而后去解一帧塞给它，这就是按需生产。可是为何还有提早生产一说呢？就是系统告诉你它要数据的时候，实际上它有一个对响应周期的要求。
你现去生产可能就要等去解完一帧，可是这个时候来得及吗？若是你只有一路下行，可能就来得及。可是如今要求不少路下行，在很短的时间周期内解不少帧，对硬件性能有很高的要求。一般来说，并不可取。这只是实时音视频中一个简单的例子。提早生产会引入延迟的，那么到底要提早多久生产，怎么样动态估计咱们何时应该生产？这是一个开放性的问题，也是一个你们在设计系统时要重点考虑的。
第二是实时音视频不能久等：
实时音视频中有些等待是避免不了的，例如你要作音频编码，它原本必定要 20 毫秒一帧或者 40 毫秒一帧去作，给一个采样点点是编不了的。这里既然有些延迟和等待避免不了，咱们固然但愿系统处理的粒度越低越好，这样可能会带来更低的延时。可是处理的粒度越低，整个系统在频繁跑的时候，你能够认为它是一套循环，当循环的东西不多，这个循环就会跑不少次，对系统来讲就是一个很大的开销和负担。
因此不能久等的时候，咱们固然但愿它处理粒度小。另外处理粒度小还有一个优点，在整个系统中并不能保证每个环节的处理粒度是一致的。例如这个节点可能要求是 10 毫秒，下一个结点要求 15 毫秒，这是因为算法的限制，可能没有办法避免。若是在整个系统内选一个相对小的粒度，在粒度拼接的时候，例如 10-15 毫秒，要两个 10 毫秒才可以 15 毫秒，还剩下 5 毫秒，剩的就比较少。
若是粒度很粗，可能剩下的东西就不少。在粒度拼接的时候，这个剩余的量表明了整个链路中的延迟。因此咱们但愿处理粒度尽可能小，可是又不能小到整个系统没有办法接受的粒度。
第三是实时音视频不能死等：
例如你须要接收一个网络包的时候，这个包迟迟不到，这个时候你不能彻底不等，彻底不等就会卡。可是在等的时候有一个超时的机制，例如这个音频包就是好久不到，就把它跳过去作一个纠帧补偿，当包最终仍是到了的时候，我也只能把它扔掉，而不该该把它利用起来。
此外，实时音视频在服务器端还须要深刻考虑这样几个问题：
第一是负载均衡；
第二是就近接入；
第三是质量评估；
第四是动态路由；
第五是算法流控。
负载均衡：是说让整个服务器的每个节点都承担相对均匀的服务，不至于使得某一个节点负载太高形成一些丢包，形成网络往返时的增大，这样对任何的网络损伤来说，对实时音视频都会形成比较大的延迟增长。
就近接入：这里的“近”并非指地域上的近，而是“网络上的近”。很简单的例子，咱们在深圳作推流，香港离得很近，能够推到香港的服务器，但实际上这毕竟是一个跨域的网络，有不稳定的因素在里面，因此咱们宁愿推远一点。这个近指的应该是在网络质量评估意义上的近，例如网络往返时很小、往返时很平稳、分布在延迟比较大的时刻不会还具备很大的几率，丢包率很低等。
要作到就近接入，这个近要有一个很好的质量评估体系，质量评估方法有两种：
过后质量评估：在复盘的时候，例如这个网络平稳的运行了一个月，复盘看一下整个月中的质量怎么样，这样的质量评估能够认为是一个相对离线的评估，它可以给咱们提供一个指标，最近一个月的网络和上个月相比是否有所改善。咱们能够从中学习到一些经验，例如这个月和上个月的调度上有些策略上的不一样。这是一个系统化的经验总结和优化的方法。
实时质量评估：更重要的应该是一个实时上的评估，例如我如今推流，可以实时监控到当前的质量是怎么样的，就能够作到实时动态路由。实时动态路由是说某我的推流从北京推到迪拜，有不少链路能够选，他可能根据以前的一些经验，假如他以前经验告诉你，直接推到迪拜，这个链路是很好的，可是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，若是很差，能够在用户无感知的状况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。
实时动态路由：是说某我的推流从北京推到迪拜，有不少链路能够选，他可能根据以前的一些经验，假如他以前经验告诉你，直接推到迪拜，这个链路是很好的，可是毕竟有个例。有动态实时的质量评估，就知道这个时候推迪拜是否好，若是很差，能够在用户无感知的状况下更换，随时增减整个链路中一些路由的节点。这就是动态路由的思路。
实际状况中是结合前面这 4 个点，在咱们的网络和服务器资源集中，去选出质量最优或者近似最优的链路来保证明时音视频的服务的。可是资源集是有限的，没有人能够保证你的资源集中必定能够选出的这个最优具备很好的链路特征。保证不了就要考虑第五点，我即便选出了一个认为是整个资源集中最优的链路，可是它的质量还达不到很好的标准，就要经过一些算法才能弥补。这些算法包括在一个不可靠的网络中怎么样进行可靠的音视频传输的技术，这些技术在接下来咱们会和你们稍微分享一下，也包括整个链路的一些拥塞控制。
六、关于信源编码的思考
信源编码是为了减小网络中的负担，把大量的数据压缩成比较小的网络数据，来减小网络负担的方式。压缩方式有不少种，咱们先以音频来看，上面画了一些图（图 6）。
咱们重点看 Opus 编码器，它有几种模式在里面：
一种是线性预测模式；
还有一种是混合模式；
另外一种是频域编码模式。
混合模式是把两种编码模式混合在一块儿，根据不一样的状况进行选择。
图 6 是一个编码器，横轴是码率，纵轴是它的质量，中间是各类音频编解码器的表现。你会发现线性预测的方式可以在低码率上提供比较好的质量，可是在 20K 左右的时候就没有曲线了，由于它不支持那么高的码率。而后看 MDCT 编码，它能够在比较高的码率上达到近似透明的音质。音频编码器是有不一样的编码原理在里面的，像这种 LP Mode 是模拟人的发声模型，既然有了数学建模，它的特征是可以在一个比较低的码率上提供一个比较可靠的质量。
可是它的特色是容易达到一种质量上的饱和，也就是说当你码率给它很高的时候，实际上它也就编的效果仍是那样，由于它毕竟是一种参数化的编码。因此根据业务场景，当你须要一个很高的音质，又须要音乐场景的时候，选择它明显不合适。MDCT MODE 没有任何的模型在里面，实际上就是把信号转换成频域，直接去量化。既然没有模型化，它是比较消耗码率的，可是它能够在一个较高的码率上提供很好的质量，但是低码率的表现远远不如模型化的方法。
总体总结起来，音频包括语音和音乐两种，所以有适合语音的 codec 和适合音乐的 codec：
第一种 codec 适合语音，语音能够模型化，适用于语音的 codec 可以在低码率上提供很好的质量，提供一个相对高的压缩比, 可是它容易达到饱和，不可以提供一个近似于透明的音质；
另一种 codec 的编码原理不同，可以把音乐、语音都编得很好，可是特色是不可以提供过高的压缩比，期望它可以在低码率下提供很高的编码质量是作不到的。
关于视频编码，最简单的几个点有 I 帧、P 帧、B 帧。I 帧是自参考，P 帧是向前参考，它会参考历史帧的特性进行编码。B 帧是双向参考，它能够参考前面的帧，也能够参考后面的帧。B 帧能够带来更高的压缩比，提供更好的质量。可是由于它会参考未来的帧，因此会引入延迟，所以咱们在实时音视频系统中是不多用到 B 帧的。
想要作好实时的音视频系统，流控是必定要作的，流控对视频的编解码有什么要求？至少有一点，编解码器的码控必定要很稳定。为何？举例说，我如今有一个很好的拥塞控制策略，带宽估计作得很好，一点差错都没有，估计出某一个时刻可分配视频的带宽就是 500kbps，就可让视频编码器设置成 500kbps。可是，若是码控不是很稳定，你设置 500kbps 的时候，视频编码器可能就跑到 600kbps 了，这样就会带来一些阻塞和延迟。所以，咱们但愿选择的 codec 具备很好的码控策略。
实际上一些开源代码都是有作码控的，可是直接拿来用并非适合你的场景，由于这些开源代码作起来，可能或多或少的考虑其余的场景，并不仅是实时音视频场景。好比说某个 codec 是用来压片的，但愿半个小时或者一个小时以内达到预约的码率就能够，不会管这一秒钟或者下一秒是什么样子的，可是实时音视频就是要求要把时间窗作得很小。
另外咱们但愿 codec 有分层编码的能力。什么是分层编码？为何要有分层编码？分层编码也分两种，一种是时域上的分层，一种是空域上的分层。前者是编码的时候是当前帧不参考上一帧，而是有隔帧参考的策略；后者能够认为使用较低的码率先编码一个小的画面，而后使用剩余的码率编码增量的部分，获得更高分辨率的画面。
为何要这样作？实时音视频中并非不少场景都是一对一的，当不是一对一，要作流控的时候，不可能由于某一路观众的下行很差，就把主播上行推流的码率降下来，由于可能还有一千个观众的网络很好，这些网络好的观众也会由于个别观众网络很差，而只能看到不那么清晰的画面。因此要分层，能够在服务器端选择给用户到底下发哪一层的，由于有分层策略，若是这我的线路很差，只要选择其中一个比较小的层次发给他就能够了，例如核心层，这样能够牢牢利用核心层把整个视频还原，可能会损伤一些细节或者帧率偏低，可是至少总体可用。
最后，我想说一下，不少人认为，视频的数据量很大，视频的延时比音频应该更高才对，实际上不是。由于不少的延迟其实是编解码自有的延迟，若是编解码中没有 B 帧的话，你能够理解为视频编码是没有任何延迟的。可是音频编码或多或少都会参考一些未来的数据，也就是说音频编码器的延时必定是存在的。所以，一般来说，音频的延时比视频的延时更高才对。
七、关于信道编码技术的思考
信道编码分几个部分：一种是根据先验知识的网络冗余编码技术——前向纠错技术。以 RS（4，6）编码为例，我要发一个分组，这个分组有六个包，其中有四个包是实际媒体数据，有两个包是冗余包。那么在解码端收到六个包中任意的四个，就能够彻底恢复全部携带媒体内容的包。
例如这里 二、3 都丢了，收到了 一、四、r一、r2，也可以彻底恢复 2 和 3。这样看来很好，任意两个丢掉均可以彻底恢复。可是这样的算法也有它的弱点，不太适合突发性的丢包。由于这个分组不宜太大，若是分组很大，分组就有很大的延时。分组若是很小，极可能整个分组都丢掉了。
实际上这种作法就没有任何意义。因此它不太适合突发性丢包，并且它毕竟是根据先验知识去作的一种冗余，也就是说它永远是根据上一时刻网络的状态做出的判断，下一时刻网络是什么样的，是预测的东西。网络是实时发生变化的，这种预测的东西并不彻底可靠。
因此它恢复的效率在实际网络中相对比较低，并且这样的算法复杂度相对比较高。固然它也有优点，例如咱们是提早算好的，一次性发过去，不须要等到你发现丢包时我再作怎样的冗余传输，因此不受网络往返的影响。并且这种分组能够任意、随机调整大小冗余度，比较适合均匀丢包的场景。
另一项技术是丢包重传技术：相对来讲，丢包重传相对 RS 来说，更有针对性，因此恢复效率比较高。第一个 Go Back N 技术是相似于 TCP 的传输技术，发送端在不断的发包，接收端要负责告诉发送端我如今收到包的状况是怎么样，收到的连续的帧的是序列号什么样的。发送端发现发了 10 个帧，接收端只正确收到 8，无论 9 号包或者 10 号包是否收到，都会丢包重传。因此 Go Back N 技术有必定的目的性，维护的是丢包状态，它知道哪些包是没有收到的，可是并不精准。
接下来是自动选择重传技术（Selective ARQ）：选择性的重传，是在接收端发现了哪一个包丢了，而后才会让发送端从新发送这个包。听起来是很是好的一个技术，效率很高，丢了哪一个包就重传哪一个包。可是它的弱点在于，你必需要假定这个包是频密的发送才能够。例如发送端发出 一、二、三、4 这样的包，可是一秒钟才发一个包，何时发现 2 丢了呢？收到 3 的时候。若是 2 做为最后一包，永远发现不了丢掉了。也就是若是发包不频密，至少须要 1 秒钟才发现它丢。这个时候再让它重传，就很晚了。
因此在一个真实的系统中，选择性重传是首选，由于音视频的大部分场景是频密的，可是可能也要结合一些 Go-Back -N 的作法。发一些确认机制，这样才能把重传作得更加完备。另外全部的重传都要至少等一个网络往还时，由于不管是确认丢包仍是反馈收包状况，都须要一个网络往返时，因此它的弱点是，它受网络往返时影响比较大，若是控制很差，有可能形成重传风暴。优点是算法计算复杂比较低，且容易实现。另外，由于它有很大的针对性，无效的重传包会比较少，针对突发性的丢包会有比较好的效果。
刚才讲了针对不可靠网络的两种传输技术，前向纠错和丢包重传，它们都有各自的优势和缺点。实际上一个好的网络分发技术应该是将这两种结合在一块儿的，根据不一样的信道状况把这两种技术结合在一块儿。
图 11 来自于网络，首先从左下角蓝色部分看起，当网络往返时很小，丢包率不高的时候就用重传。可是当网络 RTT 很高的时候，在这个图里面去看，就没有选用重传策略。从我我的的角度来看，我认为这并非一个很是合理的作法。由于刚才提到了，FEC 是一个无目的性的、根据先验知识去作的一种冗余技术，虽然当 RTT 很高，重传很耗时，但若是没有重传，要加不少冗余包，才能把丢掉的包彻底恢复，实际就会带来很大的资源浪费。并且当你丢包率很高的时候，可能还并不可以彻底恢复全部包。视频只要丢帧就会很卡，视频丢包率应该控制在千分之几如下，才能够达到顺畅的能够观看的水平。
关于信道编码的思考：信道编码和网络吞吐呈反比关系。不管是重传性编码仍是冗余性编码，都会占用带宽，从而减低实际媒体信息的吞吐量。现实的生活中，信道都有限制。当你传输的时候，就要根据信道的特征去作一些策略。信道若是有拥塞，咱们就须要有一个拥塞控制的算法，去估计应该把整个信道怎么样作合理分配。
另外，在作一个系统的时候，想清楚如何去评价一个系统的效果是很重要的一个点：在信道编码的时候，一个很重要的指标是，信道编码的有效性是什么样子的。有效性分为两种，一种是重传或者冗余可否真的把丢掉的包补回来，这是一个有效性。即便这个包补回来了，可是若是通过一个信道编码策略以后，还有一些丢包。
例如原来的丢包是 20%，补回来变成 1%，那么这个重传在咱们的评价当中其实是没有效果的，由于 1% 的丢包对音频来说是无所谓的，可是对视频来说是很卡的。在这样的评价系统中，补回来还有 1% 的丢包，那么全部的编码都是没有太大意义的。举这个例子，若是在这时信道也发生拥塞，再进行这样的信道编码，就不会达到很好的效果。这个时候是否应该中止全部的信道编码呢？
还有信道编码有效性的判断：衡量它是否好，就是加了多少冗余，冗余中有多少没有被利用好，若是这些冗余像刚才那个例子那样，6 包带 2 包的冗余，恰好丢掉 2 包，整个包都恢复出来了都使用到了，那就是百分之百的冗余都有效。若是 4 包信息丢了 1 包，却带了 2 包荣誉，其中 1 包就没有效果。因此想要作一个好的系统，应该先想到如何评价这个系统的好坏。
八、引入延迟的环节和下降延迟的思路
延迟的引入主要分三部分。
1）一个是采集 / 渲染：这好像是很简单一个部分，可是它引入延迟多是最大的，多是整个分发过程当中最大的环节。
有不少人不是特别理解，但实际上在咱们现有的网络结构中，网络往返时的延迟都控制在 50 毫秒之内，可是渲染和采集，尤为是渲染，几乎没有任何移动端系统能够保证它百分之百的 50 毫秒，这是一些硬件上的限制。如何去下降这些延迟？刚才我已经举了一个生产消费模型的思路，究竟是按需生产仍是提早生产，这些都是能够仔细去考虑的。
2）还有编解码会带来一些延迟，尤为是音频会带来一些延迟：这些延迟中有些是避免不了的，咱们就要根据实际的使用场景去减小这些延迟，这些都是要在具体形态上作一些权衡的东西。还有处理粒度上的考虑，也会影响整个系统的延迟。
3）还有一个延迟，你们都能看到的，就是网络分发延迟：如何去减少？除了在资源集中找到一个最优子集以外，还有信道编码的东西，要作一个很好的信道编码系统，咱们如何评价信道编码系统的好坏。有了这些思路以后，能够指导咱们去作更好的下一步的开发工做。
附录：更多实时音视频技术文章
[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.26四、VP8的前世此生》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《首次披露：快手是如何作到百万观众同场看直播仍能秒开且不卡顿的？》
《腾讯音视频实验室：使用AI黑科技实现超低码率的高清实时视频聊天》
《七牛云技术分享：使用QUIC协议实现实时视频直播0卡顿！》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-1465-1-1.html）
- 1. 实时视频通话超低延迟架构的思考与实践
- 2. 音视频低延迟应用的四个技术实践
- 3. 实时语音视频SDK使用FEC和ARQ实现超低延迟
- 4. 视频直播技术_直播如何实现低延迟
- 5. 低延迟系统实践
- 6. 实时音频混音技术在视频直播场景中的实践
- 7. 网页端实时音视频服务架构与实践
- 8. 实时音视频聊天中的延时问题一篇就够
- 9. WebRTC实时音视频技术的总体架构介绍
- 10. WebRTC实时音视频技术的整体架构介绍
- 更多相关文章...
- • Thymeleaf项目实践 - Thymeleaf 教程
- • 现实生活中的 XML - XML 教程
- • Docker容器实战(一) - 封神Server端技术
- • TiDB 在摩拜单车在线数据业务的应用和实践
-
每一个你不满意的现在，都有一个你没有努力的曾经。