如何实现1080P延迟低于500ms的实时超清直播传输技术

时间 2019-11-10

标签如何实现 1080p 延迟低于 500ms 实时直播传输技术繁體版

原文原文链接

再来当一次技术搬运工，内容来自高可用框架，学霸君工程师袁荣喜的如何实现1080P延迟低于500ms的实时超清直播传输技术。
html

导语：视频直播是不少技术团队及架构师关注的问题，在实时性方面，大部分直播是准实时的，存在 1-3 秒延迟。本文由袁荣喜向「高可用架构」投稿，介绍其将直播延迟控制在 500ms 的背后的实现。linux

袁荣喜，学霸君工程师，2015 年加入学霸君，负责学霸君的网络实时传输和分布式系统的架构设计和实现，专一于基础技术领域，在网络传输、数据库内核、分布式系统和并发编程方面有必定了解。

最近因为公司业务关系，须要一个在公网上能实时互动超清视频的架构和技术方案。众所周知，视频直播用 CDN + RTMP 就能够知足绝大部分视频直播业务，咱们也接触了和测试了几家 CDN 提供的方案，单人直播没有问题，一旦涉及到多人互动延迟很是大，没法进行正常的互动交谈。对于咱们作在线教育的企业来讲没有互动的直播是毫无心义的，因此咱们决定本身来构建一个超清晰（1080P）实时视频的传输方案。算法

先来解释下什么是实时视频，实时视频就是视频图像从产生到消费完成整个过程人感受不到延迟，只要符合这个要求的视频业务均可以称为实时视频。关于视频的实时性概括为三个等级：shell

伪实时：视频消费延迟超过 3 秒，单向观看实时，通用架构是 CDN + RTMP + HLS，如今基本上全部的直播都是这类技术。
准实时：视频消费延迟 1 ~ 3 秒，能进行双方互动但互动有障碍。有些直播网站经过 TCP/UDP + FLV 已经实现了这类技术，YY 直播属于这类技术。
真实时：视频消费延迟 < 1秒，平均 500 毫秒。这类技术是真正的实时技术，人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。

市面上大部分真实时视频都是 480P 或者 480P 如下的实时传输方案，用于在线教育和线上教学有必定困难，并且有时候流畅度是个很大的问题。在实现超清晰实时视频咱们作了大量尝试性的研究和探索，在这里会把大部分细节分享出来。数据库

要实时就要缩短延迟，要缩短延迟就要知道延迟是怎么产生的，视频从产生、编码、传输到最后播放消费，各个环节都会产生延迟，整体概括为下图：

成像延迟，通常的技术是毫无为力的，涉及到 CCD 相关的硬件，如今市面上最好的 CCD，一秒钟 50 帧，成像延迟也在 20 毫秒左右，通常的 CCD 只有 20 ~ 25 帧左右，成像延迟 40 ~ 50 毫秒。编程

编码延迟，和编码器有关系，在接下来的小结介绍，通常优化的空间比较小。数组

咱们着重针对网络延迟和播放缓冲延迟来进行设计，在介绍整个技术细节以前先来了解下视频编码和网络传输相关的知识和特色。服务器

1、视频编码那些事

咱们知道从 CCD 采集到的图像格式通常的 RGB 格式的（BMP），这种格式的存储空间很是大，它是用三个字节描述一个像素的颜色值，若是是 1080P 分辨率的图像空间：1920 x 1080 x 3 = 6MB，就算转换成 JPG 也有近 200KB，若是是每秒 12 帧用 JPG 也须要近 2.4MB/S 的带宽，这带宽在公网上传输是没法接受的。微信

视频编码器就是为了解决这个问题的，它会根据先后图像的变化作运动检测，经过各类压缩把变化的发送到对方，1080P 进行过 H.264 编码后带宽也就在 200KB/S ~ 300KB/S 左右。在咱们的技术方案里面咱们采用 H.264 做为默认编码器（也在研究 H.265）。网络

1.1 H.264 编码

前面提到视频编码器会根据图像的先后变化进行选择性压缩，由于刚开始接收端是没有收到任何图像，那么编码器在开始压缩的视频时须要作个全量压缩，这个全量压缩在 H.264 中 I 帧，后面的视频图像根据这个I帧来作增量压缩，这些增量压缩帧叫作 P 帧，H.264 为了防止丢包和减少带宽还引入一种双向预测编码的 B 帧，B 帧之前面的 I 或 P 帧和后面的 P 帧为参考帧。H.264 为了防止中间 P 帧丢失视频图像会一直错误它引入分组序列（GOP）编码，也就是隔一段时间发一个全量 I 帧，上一个 I 帧与下一个 I 帧之间为一个分组 GOP。它们之间的关系以下图：

PS：在实时视频当中最好不要加入 B 帧，由于 B 帧是双向预测，须要根据后面的视频帧来编码，这会增大编解码延迟。

1.2 马赛克、卡顿和秒开

前面提到若是 GOP 分组中的P帧丢失会形成解码端的图像发生错误,其实这个错误表现出来的就是马赛克。由于中间连续的运动信息丢失了，H.264 在解码的时候会根据前面的参考帧来补齐，可是补齐的并非真正的运动变化后的数据，这样就会出现颜色色差的问题，这就是所谓的马赛克现象，如图：

这种现象不是咱们想看到的。为了不这类问题的发生，通常若是发现 P 帧或者 I 帧丢失，就不显示本 GOP 内的全部帧，直到下一个 I 帧来后从新刷新图像。可是 I 帧是按照帧周期来的，须要一个比较长的时间周期，若是在下一个 I 帧来以前不显示后来的图像，那么视频就静止不动了，这就是出现了所谓的卡顿现象。若是连续丢失的视频帧太多形成解码器无帧可解，也会形成严重的卡顿现象。视频解码端的卡顿现象和马赛克现象都是由于丢帧引发的，最好的办法就是让帧尽可能不丢。

知道 H.264 的原理和分组编码技术后所谓的秒开技术就比较简单了，只要发送方从最近一个 GOP 的 I 帧开发发送给接收方，接收方就能够正常解码完成的图像并当即显示。但这会在视频链接开始的时候多发一些帧数据形成播放延迟，只要在接收端播放的时候尽可能让过时的帧数据只解码不显示，直到当前视频帧在播放时间范围以内便可。

1.3 编码延迟与码率

前面四个延迟里面咱们提到了编码延迟，编码延迟就是从 CCD 出来的 RGB 数据通过 H.264 编码器编码后出来的帧数据过程的时间。咱们在一个 8 核 CPU 的普通客户机测试了最新版本 X.264 的各个分辨率的延迟，数据以下：

从上面能够看出，超清视频的编码延迟会达到 50ms，解决编码延迟的问题只能去优化编码器内核让编码的运算更快，咱们也正在进行方面的工做。

在 1080P 分辨率下，视频编码码率会达到 300KB/S，单个 I 帧数据大小达到 80KB，单个 P 帧能够达到 30KB，这对网络实时传输形成严峻的挑战。

2、网络传输质量因素

实时互动视频一个关键的环节就是网络传输技术,无论是早期 VoIP，仍是现阶段流行的视频直播，其主要手段是经过 TCP/IP 协议来进行通讯。可是 IP 网络原本就是不可靠的传输网络，在这样的网络传输视频很容易形成卡顿现象和延迟。先来看看 IP 网络传输的几个影响网络传输质量关键因素。

2.1 TCP 和 UDP

对直播有过了解的人都会认为作视频传输首选的就是 TCP + RTMP，其实这是比较片面的。在大规模实时多媒体传输网络中，TCP 和 RTMP 都不占优点。TCP 是个拥塞公平传输的协议，它的拥塞控制都是为了保证网络的公平性而不是快速到达，咱们知道，TCP 层只有顺序到对应的报文才会提示应用层读数据，若是中间有报文乱序或者丢包都会在 TCP 作等待，因此 TCP 的发送窗口缓冲和重发机制在网络不稳定的状况下会形成延迟不可控，并且传输链路层级越多延迟会越大。

关于 TCP 的原理：
http://coolshell.cn/articles/11564.html
关于 TCP 重发延迟：
http://weibo.com/p/1001603821691477346388

在实时传输中使用 UDP 更加合理，UDP 避免了 TCP 繁重的三次握手、四次挥手和各类繁杂的传输特性，只须要在 UDP 上作一层简单的链路 QoS 监测和报文重发机制，实时性会比 TCP 好，这一点从 RTP 和 DDCP 协议能够证实这一点，咱们正式参考了这两个协议来设计本身的通讯协议。

2.2 延迟

要评估一个网络通讯质量的好坏和延迟一个重要的因素就是 Round-Trip Time（网络往返延迟）,也就是 RTT。评估两端之间的 RTT 方法很简单，大体以下：

发送端方一个带本地时间戳 T1 的 ping 报文到接收端；
接收端收到 ping 报文，以 ping 中的时间戳 T1 构建一个携带 T1 的 pong 报文发往发送端；
发送端接收到接收端发了的 pong 时，获取本地的时间戳 T2，用 T2 – T1 就是本次评测的 RTT。

示意图以下：

上面步骤的探测周期能够设为 1 秒一次。为了防止网络突发延迟增大，咱们采用了借鉴了 TCP 的 RTT 遗忘衰减的算法来计算，假设原来的 RTT 值为 rtt，本次探测的 RTT 值为 keep_rtt。那么新的 RTT 为：

new_rtt = (7 * rtt + keep_rtt) / 8

可能每次探测出来的 keep_rtt 会不同，咱们须要会计算一个 RTT 的修正值 rtt_var，算法以下：

new_rtt_var = (rtt_var * 3 + abs(rtt – keep_rtt)) / 4

rtt_var 其实就是网络抖动的时间差值。

若是 RTT 太大，表示网络延迟很大。咱们在端到端之间的网络路径同时保持多条而且实时探测其网络状态，若是 RTT 超出延迟范围会进行传输路径切换（本地网络拥塞除外）。

2.3 抖动和乱序

UDP 除了延迟外，还会出现网络抖动。什么是抖动呢？举个例子，假如咱们每秒发送 10 帧视频帧，发送方与接收方的延迟为 50MS，每帧数据用一个 UDP 报文来承载，那么发送方发送数据的频率是 100ms 一个数据报文，表示第一个报文发送时刻 0ms， T2 表示第二个报文发送时刻 100ms . . .，若是是理想状态下接收方接收到的报文的时刻依次是（50ms, 150ms, 250ms, 350ms….），但因为传输的缘由接收方收到的报文的相对时刻多是（50ms, 120ms, 240ms, 360ms ….），接收方实际接收报文的时刻和理想状态时刻的差值就是抖动。以下示意图：

咱们知道视频必须按照严格是时间戳来播放，不然的就会出现视频动做加快或者放慢的现象，若是咱们按照接收到视频数据就当即播放，那么这种加快和放慢的现象会很是频繁和明显。也就是说网络抖动会严重影响视频播放的质量，通常为了解决这个问题会设计一个视频播放缓冲区，经过缓冲接收到的视频帧，再按视频帧内部的时间戳来播放既能够了。

UDP 除了小范围的抖动之外，仍是出现大范围的乱序现象，就是后发的报文先于先发的报文到达接收方。乱序会形成视频帧顺序错乱，通常解决的这个问题会在视频播放缓冲区里作一个前后排序功能让先发送的报文先进行播放。

播放缓冲区的设计很是讲究，若是缓冲过多帧数据会形成没必要要的延迟，若是缓冲帧数据过少，会由于抖动和乱序问题形成播放无数据能够播的状况发生，会引发必定程度的卡顿。关于播放缓冲区内部的设计细节咱们在后面的小节中详细介绍。

2.4 丢包

UDP 在传输过程还会出现丢包，丢失的缘由有多种，例如：网络出口不足、中间网络路由拥堵、socket 收发缓冲区过小、硬件问题、传输损耗问题等等。在基于 UDP 视频传输过程当中，丢包是很是频繁发生的事情，丢包会形成视频解码器丢帧，从而引发视频播放卡顿。这也是大部分视频直播用 TCP 和 RTMP 的缘由，由于 TCP 底层有本身的重传机制，能够保证在网络正常的状况下视频在传输过程不丢。基于 UDP 丢包补偿方式通常有如下几种：

报文冗余

报文冗余很好理解，就是一个报文在发送的时候发送 2 次或者屡次。这个作的好处是简单并且延迟小，坏处就是须要额外 N 倍（N 取决于发送的次数）的带宽。

FEC

Forward Error Correction，即向前纠错算法，经常使用的算法有纠删码技术（EC），在分布式存储系统中比较常见。最简单的就是 A B 两个报文进行 XOR（与或操做）获得 C，同时把这三个报文发往接收端，若是接收端只收到 AC,经过 A 和 C 的 XOR 操做就能够获得 B 操做。这种方法相对增长的额外带宽比较小，也能防止必定的丢包，延迟也比较小，一般用于实时语音传输上。对于 1080P 300KB/S 码率的超清晰视频，哪怕是增长 20% 的额外带宽都是不可接受的，因此视频传输不太建议采用 FEC 机制。

丢包重传

丢包重传有两种方式，一种是 push 方式，一种是 pull 方式。Push 方式是发送方没有收到接收方的收包确认进行周期性重传，TCP 用的是 push 方式。pull 方式是接收方发现报文丢失后发送一个重传请求给发送方，让发送方重传丢失的报文。丢包重传是按需重传，比较适合视频传输的应用场景，不会增长太对额外的带宽，但一旦丢包会引来至少一个 RTT 的延迟。

2.5 MTU 和最大 UDP

IP 网定义单个 IP 报文最大的大小，经常使用 MTU 状况以下：

超通道 65535
16Mb/s 令牌环 179144
Mb/s 令牌环 4464
FDDI 4352
以太网 1500
IEEE 802.3/802.2 1492
X.25 576
点对点（低时延）296

红色的是 Internet 使用的上网方式，其中 X.25 是个比较老的上网方式，主要是利用 ISDN 或者电话线上网的设备，也不排除有些家用路由器沿用 X.25 标准来设计。因此咱们必须清晰知道每一个用户端的 MTU 多大，简单的办法就是在初始化阶段用各类大小的 UDP 报文来探测 MTU 的大小。MTU 的大小会影响到咱们视频帧分片的大小，视频帧分片的大小其实就是单个 UDP 报文最大承载的数据大小。

分片大小 = MTU – IP 头大小 – UDP 头大小 – 协议头大小;
IP 头大小 = 20 字节， UDP 头大小 = 8 字节。

为了适应网络路由器小包优先的特性，咱们若是获得的分片大小超过 800 时，会直接默认成 800 大小的分片。

3、传输模型

咱们根据视频编码和网络传输获得特性对 1080P 超清视频的实时传输设计了一个本身的传输模型，这个模型包括一个根据网络状态自动码率的编解码器对象、一个网络发送模块、一个网络接收模块和一个 UDP 可靠到达的协议模型。各个模块的关系示意图以下：

3.1 通讯协议

先来看通讯协议，咱们定义的通讯协议分为三个阶段：接入协商阶段、传输阶段、断开阶段。

接入协商阶段

主要是发送端发起一个视频传输接入请求，携带本地的视频的当前状态、起始帧序号、时间戳和 MTU 大小等，接收方在收到这个请求后，根据请求中视频信息初始化本地的接收通道，并对本地 MTU 和发送端 MTU 进行比较取二者中较小的回送给发送方，让发送方按协商后的 MTU 来分片。示意图以下：

传输阶段

传输阶段有几个协议，一个测试量 RTT 的 PING/PONG 协议、携带视频帧分片的数据协议、数据反馈协议和发送端同步纠正协议。其中数据反馈协议是由接收反馈给发送方的，携带接收方已经接收到连续帧的报文 ID、帧 ID 和请求重传的报文 ID 序列。同步纠正协议是由发送端主动丢弃发送窗口缓冲区中的报文后要求接收方同步到当前发送窗口位置，防止在发送主动丢弃帧数据后接收方一直要求发送方重发丢弃的数据。示意图以下:

断开阶段

就一个断开请求和一个断开确认，发送方和接收方均可以发起断开请求。

3.2 发送

发送主要包括视频帧分片算法、发送窗口缓冲区、拥塞判断算法、过时帧丢弃算法和重传。先一个个来介绍。

帧分片

前面咱们提到 MTU 和视频帧大小，在 1080P 下大部分视频帧的大小都大于 UDP 的 MTU 大小，那么就须要对帧进行分片，分片的方法很简单，按照先链接过程协商后的 MTU 大小来肯定分片大小（肯定分片大小的算法在 MTU 小节已经介绍过），而后将帧数据按照分片大小切分红若干份，每一份分片以 segment 报文形式发往接收方。

重传

重传比较简单，咱们采用 pull 方式来实现重传，当接收方发生丢包，若是丢包的时刻 T1 + rtt_var< 接收方当前的时刻 T2，就认为是丢包了，这个时候就会把全部知足这个条件丢失的报文 ID 构建一个 segment ack 反馈给发送方，发送方收到这个反馈根据 ID 到重发窗口缓冲区中查找对应的报文重发便可。

为何要间隔一个 rtt_var 才认为是丢包了？由于报文是有可能乱序到达，全部要等待一个抖动周期后认为丢失的报文尚未来才确认是报文丢失了，若是检测到丢包当即发送反馈要求重传，有可能会让发送端多发数据，形成带宽让费和网络拥塞。

发送窗口缓冲区

发送窗口缓冲区保存这全部正在发送且没有获得发送方连续 ID 确认的报文。当接收方反馈最新的连续报文 ID，发送窗口缓冲就会删除全部小于最新反馈连续的报文 ID，发送窗口缓冲区缓冲的报文都是为了重发而存在。这里解释下接收方反馈的连续的报文 ID，举个例子，假如发送方发送了 1. 2. 3. 4. 5，接收方收到 1.2. 4. 5。这个时候最小连续 ID = 2，若是后面又来了 3，那么接收方最小连续 ID = 5。

拥塞判断

咱们把当前时间戳记为 curr_T，把发送窗口缓冲区中最老的报文的时间戳记为 oldest_T，它们之间的间隔记为 delay，那么

delay = curr_T - oldest_T

在编码器请求发送模块发送新的视频帧时，若是 delay > 拥塞阈值 Tn，咱们就认为网络拥塞了，这个时候会根据最近 20 秒接收端确认收到的数据大小计算一个带宽值，并把这个带宽值反馈给编码器，编码器收到反馈后，会根据带宽调整编码码率。若是屡次发生要求下降码率的反馈，咱们会缩小图像的分辨率来保证视频的流畅性和实时性。Tn 的值能够经过 rtt 和 rtt_var 来肯定。

可是网络可能阶段性拥塞，事后却恢复正常，咱们设计了一个定时器来定时检查发送方的重发报文数量和 delay，若是发现恢复正常，会逐步增大编码器编码码率，让视频恢复到指定的分辨率和清晰度。

过时帧丢弃

在网络拥塞时可能发送窗口缓冲区中有不少报文正在发送，为了缓解拥塞和减小延迟咱们会对整个缓冲区作检查，若是有超过必定阈值时间的 H.264 GOP 分组存在，咱们会将这个 GOP 全部帧的报文从窗口缓冲区移除。并将它下一个 GOP 分组的 I 的帧 ID 和报文 ID 经过 wnd sync 协议同步到接收端上，接收端接收到这个协议，会将最新连续 ID 设置成同步过来的 ID。这里必需要说明的是若是频繁出现过时帧丢弃的动做会形成卡顿，说明当前网络不适合传输高分辨率视频，能够直接将视频设成更小的分辨率。

3.3 接收

接收主要包括丢包管理、播放缓冲区、缓冲时间评估和播放控制，都是围绕播放缓冲区来实现的，一个个来介绍。

丢包管理

丢包管理包括丢包检测和丢失报文 ID 管理两部分。丢包检测过程大体是这样的，假设播放缓冲区的最大报文 ID 为 max_id，网络上新收到的报文 ID 为 new_id，若是 max_id + 1 < new_id，那么可能发生丢包，就会将 [max_id + 1, new_id -1] 区间中全部的 ID 和当前时刻做为 K/V 对加入到丢包管理器当中。若是 new_id < max_id，那么就将丢包管理中的 new_id 对应的 K/V 对删除，表示丢失的报文已经收到。当收包反馈条件知足时，会扫描整个丢包管理，将达到请求重传的丢包 ID 加入到 segment ack 反馈消息中并发往发送方请求重传，若是 ID 被请求了重传，会将当前时刻设置为 K/V 对中，增长对应报文的重传计数器 count，这个扫描过程会统计对包管理器中单个重发最多报文的重发次数 resend_count。

缓冲时间评估

在前面的抖动与乱序小节中咱们提到播放端有个缓冲区，这个缓冲区过大时延迟就大，缓冲区太小时又会出现卡顿现象，咱们针对这个问题设计了一个缓冲时间评估的算法。缓冲区评估先会算出一个 cache timer，cache timer 是经过扫描对包管理获得的 resend count 和 rtt 获得的，咱们知道从请求重传报文到接收方收到重传的报文的时间间隔是一个 RTT 周期，因此 cache timer 的计算方式以下。

cache timer = (2 resend_count+ 1) (rtt + rtt_var) / 2

有可能 cache timer 计算出来很小（小于视频帧之间间隔时间 frame timer），那么 cache timer = frame timer，也就是说网络再好，缓冲区缓冲区至少 1 帧视频的数据，不然缓冲区是毫无心义的。

若是单位时间内没有丢包重传发生，那么 cache timer 会作适当的缩小，这样作的好处是当网络间歇性波动形成 cache timer 很大，恢复正常后 cache timer 也能恢复到相对小位置，缩减没必要要的缓冲区延迟。

播放缓冲区

咱们设计的播放缓冲区是按帧 ID 为索引的有序循环数组，数组内部的单元是视频帧的具体信息：帧 ID、分片数、帧类型等。缓冲区有两个状态：waiting 和 playing，waiting 状态表示缓冲区处于缓冲状态，不能进行视频播放直到缓冲区中的帧数据达到必定的阈值。Playing 状态表示缓冲区进入播放状态，播放模块能够从中取出帧进行解码播放。咱们来介绍下这两个状态的切换关系：

当缓冲区建立时会被初始化成 waiting 状态。
当缓冲区中缓冲的最新帧与最老帧的时间戳间隔 > cache timer 时，进入 playing 状态并更当前时刻设成播放绝对时间戳 play ts。
当缓冲区处于 playing 状态且缓冲区是没有任何帧数据，进入 waiting 状态直到触发第 2 步。

播放缓冲区的目的就是防止抖动和应对丢包重传，让视频流能按照采集时的频率进行播放，播放缓冲区的设计极其复杂，须要考虑的因素不少，实现的时候须要慎重。

播放控制

接收端最后一个环节就是播放控制，播放控制就是从缓冲区中拿出有效的视频帧进行解码播放。可是怎么拿？何时拿？咱们知道视频是按照视频帧从发送端携带过来的相对时间戳来作播放，咱们每一帧视频都有一个相对时间戳 TS，根据帧与帧之间的 TS 的差值就能够知道上一帧和下一帧播放的时间间隔，假如上一帧播放的绝对时间戳为 prev_play_ts，相对时间戳为 prev_ts，当前系统时间戳为 curr_play_ts，当前缓冲区中最小序号帧的相对时间戳为 frame_ts，只要知足：

Prev_play_ts + (frame_ts – prev_ts) < curr_play_ts 且这一帧数据是全部的报文都收齐了

这两个条件就能够进行解码播放，取出帧数据后将 Prev_play_ts = cur_play_ts，但更新 prev_ts 有些讲究，为了防止缓冲延迟问题咱们作了特殊处理。

若是 frame_ts + cache timer < 缓冲区中最大帧的 ts，代表缓冲的时延太长，则 prev_ts = 缓冲区中最大帧的 ts - cache timer。不然 prev_ts = frame_ts。

4、测量

再好的模型也须要有合理的测量方式来验证，在多媒体这种具备时效性的传输领域尤为如此。通常在实验室环境咱们采用 netem 来进行模拟公网的各类状况进行测试，若是在模拟环境已经达到一个比较理想的状态后会组织相关人员在公网上进行测试。下面来介绍怎么来测试咱们整个传输模型的。

4.1 netem 模拟测试

Netem 是 Linux 内核提供的一个网络模拟工具，能够设置延迟、丢包、抖动、乱序和包损坏等，基本能模拟公网大部分网络状况。

关于 netem 能够访问它的官网：
https://wiki.linuxfoundation.org/networking/netem

咱们在实验环境搭建了一个基于服务器和客户端模式的测试环境，下面是测试环境的拓扑关系图：

咱们利用 Linux 来作一个路由器，服务器和收发端都链接到这个路由器上，服务器负责客户端的登记、数据转发、数据缓冲等，至关于一个简易的流媒体服务器。Sender 负责媒体编码和发送，receiver 负责接收和媒体播放。为了测试延迟，咱们把 sender 和 receiver 运行在同一个 PC 机器上，在 sender 从 CCD 获取到 RGB 图像时打一个时间戳，并把这个时间戳记录在这一帧数据的报文发往 server 和 receiver，receiver 收到并解码显示这帧数据时，经过记录的时间戳能够获得整个过程的延迟。咱们的测试用例是用 1080P 码率为 300KB/S 视频流，在 router 用 netem 上模拟了如下几种网络状态：

环路延迟 10m，无丢包，无抖动，无乱序
环路延迟 30ms，丢包 0.5%，抖动 5ms, 2% 乱序
环路延迟 60ms，丢包 1%，抖动 20ms, 3% 乱序，0.1% 包损坏
环路延迟 100ms，丢包 4%，抖动 50ms, 4% 乱序，0.1% 包损坏
环路延迟 200ms，丢包 10%，抖动 70ms, 5% 乱序，0.1% 包损坏
环路延迟 300ms，丢包 15%，抖动 100ms, 5% 乱序，0.1% 包损坏

由于传输机制采用的是可靠到达，那么检验传输机制有效的参数就是视频延迟，咱们统计 2 分钟周期内最大延迟，如下是各类状况的延迟曲线图：

从上图能够看出，若是网络控制在环路延迟在 200ms 丢包在 10% 如下，可让视频延迟在 500ms 毫秒如下，这并非一个对网络质量要求很苛刻的条件。因此咱们在后台的媒体服务部署时，尽可能让客户端到媒体服务器之间的网络知足这个条件，若是网路环路延迟在 300ms 丢包 15% 时，依然能够作到小于 1 秒的延迟，基本能知足双向互动交流。

4.2 公网测试

公网测试相对比较简单，咱们将 Server 部署到 UCloud 云上，发送端用的是上海电信 100M 公司宽带，接收端用的是河北联通 20M 小区宽带，环路延迟在 60ms 左右。整体测试下来 1080P 在接收端观看视频流畅天然，无抖动，无卡顿，延迟统计平均在 180ms 左右。

5、坑

在整个 1080P 超清视频的传输技术实现过程当中，咱们遇到过比较多的坑。大体以下：

Socket 缓冲区问题

咱们前期开发阶段都是使用 socket 默认的缓冲区大小，因为 1080P 图像帧的数据很是巨大（关键帧超过 80KB），咱们发如今在内网测试没有设置丢包的网络环境发现接收端有严重的丢包，经查证是 socket 收发缓冲区过小形成丢包的，后来咱们把 socket 缓冲区设置到 128KB 大小，问题解决了。

H.264 B 帧延迟问题

前期咱们为了节省传输带宽和防丢包开了 B 帧编码，因为 B 帧是先后双向预测编码的，会在编码期滞后几个帧间隔时间，引发了超过 100ms 的编码延时，后来咱们为了实时性干脆把 B 帧编码选项去掉。

Push 方式丢包重传

在设计阶段咱们曾经使用发送端主动 push 方式来解决丢包重传问题，在测试过程发如今丢包频繁发生的状况下至少增长了 20% 的带宽消耗，并且容易带来延迟和网络拥塞。后来几经论证用如今的 pull 模式来进行丢包重传。

Segment 内存问题

在设计阶段咱们对每一个视频缓冲区中的帧信息都是动态分配内存对象的，因为 1080P 在传输过程当中每秒会发送 400 - 500 个 UDP 报文，在 PC 端长时间运行容易出现内存碎片，在服务器端出现莫名其妙的 clib 假内存泄露和并发问题。咱们实现了一个 memory slab 管理频繁申请和释放内存的问题。

音频和视频数据传输问题

在早期的设计之中咱们借鉴了 FLV 的方式将音频和视频数据用同一套传输算法传输，好处就是容易实现，但在网络波动的状况下容易引发声音卡顿，也没法根据音频的特性优化传输。后来咱们把音频独立出来，针对音频的特性设计了一套低延迟高质量的音频传输体系，定点对音频进行传输优化。

后续的工做是重点放在媒体器多点分布、多点并发传输、P2P 分发算法的探索上，尽可能减小延迟和服务带宽成本,让传输变的更高效和更低廉。

Q&A

提问：在优化到 500ms 方案中，哪一块是最关键的？
袁荣喜：主要是丢包重传拥塞和播放缓冲这三者之间的协调工做最为关键，要兼顾延迟控制和视频流畅性。

提问：多方视频和单方有哪些区别，用到了 CDN 推流吗？
袁荣喜：咱们公司是作在线教育的，不少场景须要老师和学生交谈，用 CDN 推流方式延迟很大，咱们这个视频主要是解决多方通讯之间交谈延迟的问题。咱们如今观看放也有用 CDN 推流，但只是单纯的观看。咱们也在研发基于 UDP 的观看端分发协议，目前这部分工做尚未完成。

from:http://windrunnerlihuan.com/2016/09/18/如何实现1080P延迟低于500ms的实时超清直播传输技术/