ACTK：调研
音视频延迟调研和分析
视频延迟
关于视频的实时性归纳为三个等级：
- 伪实时：视频消费延迟超过 3 秒，单向观看实时，通用架构是 CDN + RTMP + HLS，现在基本上所有的直播都是这类技术；
- 准实时： 视频消费延迟 1 ~ 3 秒，能进行双方互动但互动有障碍。有些直播网站通过 TCP/UDP + FLV 已经实现了这类技术，YY 直播属于这类技术；
- 真实时：视频消费延迟 < 1秒，平均 500 毫秒。这类技术是真正的实时技术，人和人交谈没有明显延迟感。QQ、微信、Skype 和 WebRTC 等都已经实现了这类技术。
音频延迟
对于严格的音频通话，当延时高于200ms时，就会影响到用户体验。达到400ms对方用户就容易感知出来，1s以上的延迟对于交互式实时直播就不能接受了
音视频延迟分类
音视频从生产到消费的各个环节都需要花费时间来处理，这些时间之和就造成了视频观看方看的视频是
视频产生方几秒之前产生的视频。我们对这些延时进行区分，会总结出以下四种类型的延时：
- 处理延时：一般就是路由器要分析数据包头决定这个数据包要送到下一站花费的时间；
- 排队延时：数据包从进入到路由器的发送队列到被发送之间经过的时间，路由排队算法和网络都会影响这部分延时。
- 传输延时：将数据包传入到线路花费的时间，跟数据包的大小和带宽有关系。
- 传播延时：是指数据包第一个bit位从发送端到接收端的时间，其和传输距离和传播速度有关系。
其实对于音视频系统，我们可以将上面讲述的三种延时归纳为下面几种：
【第一】设备端的延时：包括数据的采集、前处理、编码、解码、渲染等处理阶段花费的时间。也就是A1和A5花费的时间。
- 音频部分：音频从采集后，会经过模数转换，将传统的模拟信号转换成数字信号就会产生延时，一般在10ms级别；采集后，进行编码，采用不同的音频编码器也会产生不同的延时，以Opus为例，延时也在2.5ms-60ms级别。发送前还需要进行3A算法（AEC、ANS、AGC）的处理，又需要十几ms.
- 视频部分：从自然采光到成像，取决于CCD和CMOS的成像效率，不过一般也需要几十ms.对采集的RGB数据要进行YUV转换和编码，如果还有B帧会产生比较大的编码延时，紧接着播放端的渲染也是需要一定时间的。
无论音频还是视频，为了防止抖动我们一般会在播放端加上 jitter buffer 缓存，数据从进入到缓存到出缓存以及当发生丢包时，进行的一些传输算法处理也是需要一定的时间，大概会在几十毫秒到几百毫秒之间。
【第二】设备端和服务器的延时：也就是俗称的第一公里和最后一公里的延时，包括了A1到A2推流产生的延时和A5向A4拉流的延时。这里的延时跟设备端距离服务器的物理距离，服务器和设备端的网络运营商，设备的网速和带宽，设备端自己的负载都有密切关系。
【第三】服务器之间的延时：包含了音视频数据在网络上进行再次转码、切片、转封装和协议以及分发CDN等花费的时间，包含了A2到A4整个阶段花费的时间。这里要看设备的推流端和播放端是不是在同一个边缘节点，如果属于同一个边缘节点，那延时能小点。国内城市之间的传播延时也在几十毫秒，如果跨洲延时
会达到百毫秒以上。所以单就降低实时音视频系统延时一项内容，都不是靠只优化一个节点或者一个阶段就能达到你想要的预期效果，必须站在音视频整个系统来看待。
延迟优化方案
经过以上分析，我们可以得出延时产生的阶段和节点，这样优化延时就有了方法。延时会产生在：
- 音视频数据的前处理；
- 音视频数据的编解码；
- 音视频数据的网络传输；
- 为了防止抖动业务代码中的缓冲区，包括推流服务、转码服务、播放器的缓存等；
- 音视频的渲染播放；
当然上面会产生延时的地方对于最终的延时影响权重是不一样的，其中数据的前处理、编解码、渲染对于延时影响比较小，而网络传输和业务代码的缓存对于延时影响非常大。所以优化也要结合你的业务有重点进行。
【优化思路1】：调整推流端和播放端的缓冲区大小，对于25fps的视频流，如果我们缓存25帧的数据，就会在播放时产生1s的延时。所以我们要动态调整我们的缓冲区，对于推流上行区我们如果带宽不够就会产生网络阻塞，这时发送端的数据就会积累，最终延时不断累加，导致延时变大。我们此时就需要有一套机制来能够预测带宽，降低发送码率，减低当前发送数据量，减少网络阻塞，等网络好的时候再继续增大数据发送量，增大码率。
上面说的这些算法有很多，其中WebRTC方案就采用了GCC算法，还有一些类似BBR的算法来实现上述想法。
对于播放端的缓存，当网络不好产生的延时比较大时，我们需要通过丢帧和加速播放方式快速消耗掉播放缓冲区的数据，从而消除累计的延时。
【优化思路2】：优化网络传输，如果实时性要求很高的场景，你如果选用基于TCP承载的网络传输协议，无论你怎么优化，也很难降低延时。因为TCP会进行三次握手，而且它会对每一次发送的数据进行确认，还要对丢包进行重传，所以这些限制很不适合降低延时。我们要优化传输协议，我们可以将基于TCP的RTMP、HLS协议切换到基于UDP的RTP、QUIC协议上，或者自己开发基于UDP的私有协议栈，这样我们就可以对一些TCP延时大的功能进行裁剪和修改，对于一些不关重要的数据进行丢弃，优先保障重要数据的传输。其中国内B站、虎牙直播，在线k12教育等都进行了类似的处理；
【优化思路3】：选择优质的 CDN加速 服务，保障传输的线路带宽和线路资源，一般都会提供测速选线、动态监测、智能路由等功能。
【优化思路4】：如果感觉自己的编解码，前期处理等花费时间比较多，我们就需要选择合适的音视频编解码器，进行算法调优降低延时，比如我们在播放端能支持硬解的优先选择硬解否则才选择软解。
网络架构调研
实现方式
- P2P
- 流媒体服务器：rtmp
- winsocket
协议：RTP (基于UDP，延迟低)
