关于直播、CDN、直播协议的学习总结

视频是怎么组成的

任何一个视频 Video 文件，从结构上讲，都是这样一种组成方式：

• 由图像和音频构成最基本的内容元素；

  
  image.png

• 具体刨析结构可包括：

  
  image.png

• 对一个完整的视频的封装过程的简单理解

  
  image.png

为了便于视频内容的存储和传输，通常需要减少视频内容的体积，也就是需要将原始的内容元素(图像和音频)经过压缩，压缩算法也简称编码格式。有编码器也就有相应的解码器，编码器将多张图像进行编码后生产成一段一段的 GOP ( Group of Pictures ) ， 解码器在播放时则是读取一段一段的 GOP 进行解码后读取画面再渲染显示。

• 编码器

• 解码器

  
  image.png
  

  GOP ( Group of Pictures ) 是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。I 帧是内部编码帧（I 帧不是关键帧，IDR 帧才是。IDR 帧是 I 帧，但是 I 帧不一定是 IDR 帧。只有 IDR 帧才是可重入的），P 帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。如果没有 I 帧，P 帧和 B 帧就无法解码。

  
  image.png
  image.png

---

什么是视频直播？

直播就是将每一帧数据 ( Video / Audio / Data Frame )，打上时序标签 ( Timestamp ) 后进行流式传输的过程。

• 直播的基本过程（边生产，边传输，边消费）

  
  image.png

• 整体的较详细的过程

  
  直播整体流程.png

用简单的图来解释学习相关的知识点

image.png

• 推流
  推流是指把采集阶段封包好的内容传输到服务器的过程
• 拉流
  拉流是指服务器已有直播内容，用指定地址进行拉取的过程
• • 这个过程中的相关协议学习，搜集相关资料
    非常好的关于相关协议的总结学习的一些链接，进一步了解协议及其之间的区别；超低延迟的解决方案的了解，进一步理解CDN拉流和自搭流媒体服务器的区别。
    各协议区别：
    https://www.cnblogs.com/my_life/articles/5593892.html
    超低延迟解决方案：
    https://blog.csdn.net/zhiboshequ/article/details/79955433
    https://blog.csdn.net/erlib/article/details/52944839
    了解UDP协议：
    https://baike.so.com/doc/5418284-5656447.html
    CDN原理学习：
    https://mp.weixin.qq.com/s?__biz=MzI4MTY5NTk4Ng==&mid=2247489552&idx=1&sn=5c828588202090f214d467c8bb7584f1&chksm=eba41b8ddcd3929b1ef44a0d2fe62ea8267643177df6c50ceeeb512e4e7865afc303b35c1de1&m
    直播流程学习：
    https://www.jianshu.com/p/19452b370e77?utm_campaign=haruki&utm_content=note&utm_medium=reader_share&utm_source=qq&from=timeline&isappinstalled=1
    其他链接：
    https://www.jianshu.com/p/f698d6481634

---

待总结

---

• RTMP (Real Time Messaging Protocol，实时消息传送协议)
  RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：
  1）工作在TCP之上的明文协议，使用端口1935；
  2）RTMPT封装在HTTP请求之中，可穿越防火墙；
  3）RTMPS类似RTMPT，但使用的是HTTPS连接；
  RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。
• RTSP (Real Time Streaming Protocol，实时流传输协议)
  RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。
  RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。
• RTP (Real-time Transport Protocol，实时传输协议)
  RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。
  RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。
  RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。
• RTCP (Real-time Transport Control Protocol，实时传输控制协议）
  RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。
  RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。

---

影响视觉体验的直播性能指标

• 延迟
  延迟是数据从信息源发送到目的地所需的时间
  原因可能是：
  由于 RTMP/HLS 是基于 TCP 之上的应用层协议，TCP 三次握手，四次挥手，慢启动过程中的每一次往返来回，都会加上一次往返耗时 ( RTT )，这些交互过程都会增加延迟。其次根据 TCP 丢包重传特性，网络抖动可能导致丢包重传，也会间接导致延迟加大。

• 卡顿
  是指视频播放过程中出现画面滞帧，让人们明显感觉到“卡”。单位时间内的播放卡顿次数统计称之为卡顿率。
  原因可能是：
  -- 推流端发送数据中断
  -- 公网传输拥塞或网络抖动异常
  -- 终端设备的解码性能太差

• 首屏耗时
  指第一次点击播放后，肉眼看到画面所等待的时间。技术上指播放器解码第一帧渲染显示画面所花的耗时。通常说的 “秒开”，指点击播放后，一秒内即可看到播放画面。

结合上面的指标，用户的体验诉求基本为：低延迟、高清流畅、极速秒开

---

CDN的学习

• 直播的流程
  CDN直播图.png
  CDN的全称为Content Delivery Network，即内容分发网络，是一个策略性部署的整体系统，主要用来解决由于网络带宽小、用户访问量大、网点分布不均匀等导致用户访问网站速度慢的问题。
  image.png
  CDN直播中常用的流媒体协议包括RTMP、HLS、HTTP FLV等。（详细的了解见相关链接）
• CDN的基本架构
  CDN主要包含源站、缓存服务器、智能DNS、客户端等几个主要组成部分。

源站是指发布内容的原始站点。添加、删除和更改网站的文件，都是在源站上进行的；另外缓存服务器所抓取的对象也全部来自于源站。对于直播来说，源站为主播客户端。

缓存服务器是直接提供给用户访问的站点资源，由一台或数台服务器组成；当用户发起访问时，他的访问请求被智能DNS定位到离他较近的缓存服务器。如果用户所请求的内容刚好在缓存里面，则直接把内容返还给用户；如果访问所需的内容没有被缓存，则缓存服务器向邻近的缓存服务器或直接向源站抓取内容，然后再返还给用户。

智能DNS是整个CDN技术的核心，它主要根据用户的来源，以及当前缓存服务器的负载情况等，将其访问请求指向离用户比较近且负载较小的缓存服务器。通过智能DNS解析，让用户访问同服务商下、负载较小的服务器，可以消除网络访问慢的问题，达到加速作用。

客户端即发起访问的普通用户。对于直播来说，就是观众客户端。

image.png

• • 有关于CDN延迟问题
    1.网络延迟
    延迟是数据从信息源发送到目的地所需的时间。
    如说下图中的网络延时：
    image
    这里不考虑主播段采集对视频进行编码的时间，以及观众端观看对视频进行解码的时间，仅考虑网络传输中的延时，假设在该链路上有缓存，时间为Tmax_cache ，那么从主播到观众的延时Tdelay为：
    image
    另外，数据传输过程中还涉及到逻辑上的交互，例如包的重传以及确认，以及缓存上的一些逻辑等，会在这个基础上又增加很多。
    2.网络抖动
    网络抖动，是指数据包的到达顺序、间隔和发出时不一致。网络抖动，是指数据包的到达顺序、间隔和发出时不一致。如果网络中抖动较大，会造成播放卡顿等现象。 image
    如上图所示，主播端t3和t5发出的包，分别在t3'和t5'到达，但是中间延时增大，即发生了网络抖动。这样造成观众端观看视频的延时会不断增大。
    3.网络丢包
    CDN直播中用到的RTMP、HLS、HTTP FLV等协议都是在TCP的基础之上。TCP一个很重要的特性是可靠性，即不会发生数据丢失的问题。为了保证可靠性，TCP在传输过程中有3次握手，见下图。首先客户端会向服务端发送连接请求，服务端同意后，客户端会确认这次连接。这就是3次握手。接着，客户端就开始发送数据，每次发送一批数据，得到服务端的“收到”确认后，继续发送下一批。TCP为了保证传到，会有自动重传机制。如果传输中发生了丢包，没有收到对端发出的“收到”信号，那么就会自动重传丢失的包，一直到超时。
    image

• • 解决方案
    抛弃传统的基于TCP协议的方案，从底层协议和布网上开始，使用基于UDP协议的方案。SD-RTN（Software-Defined Real Time Net work），软件定义实时传输网络，是一种新型的专为内容实时传输而设计，基于UDP协议的网络架构。SD-RTN通过在互联网上不同地区的数据中心放置软件组网单元，相互连接互相调度，在现有的公共互联网基础上构建一层新的虚拟网络。能够实时根据各节点的连接、传输状况、负载状况、到用户的距离和响应时间，自动分配最优最通畅的传输路径，达到实时传输需要的质量保障级别。

CDN与SD-RTN对比情况如下：

• 基本原理不同。CDN是存储转发结构，设计目的是在各个边缘节点缓存待分发内容，结构上从源站到观众是伞状多级缓存放大方式。SD-RTN本质上一个实时传输网络，用户的数据在网络单元内部和传输线路上都以实时交换方式传送，UDP实现的传输协议，不会因为前一个包的丢失或延迟导致下后续包的延迟送达，而丢包可以用对延迟更友好的方式修复或补偿出来，从而能够保证最低延迟。

• 底层协议不同。SD-RTN采用了专为实时传输设计的UDP协议，避免了采用TCP的延时不可控缺点。能够大大缩短交互延时，延时可从CDN方案的数秒，降低到数百毫秒。

• 内容分发机制不同。SD-RTN是基于自定义路由，选择最优传输路径，直接将内容端到端传输，数据在网络单元中从不缓存，从而最大可能的降低延迟，同时内容安全性也更好。CDN是将内容缓存于缓存服务器中，再将内容就近下发，所以CDN更适合做内容分发，一对多的场景。

• 使用场景不同。SD-RTN适用于要求极低时延的实时互动场景，例如网络电话、视频会议、有主播与观众交互需求的互动直播等。CDN适用于对时延要求不高的场景，例如对延时要求不高、类似电视的单点直播、网站加速等。

SD-RTN的优势如下：

• 时延大大缩短。直播延时可从基于TCP的方案的数秒，降低到数百毫秒。这一延迟范围，属于实时通信或准实时通信延迟的范畴。在这一级别上，主播和观众可以基本重现在现场活动中的交互体验，从而大大释放了内容制作者的潜力，也为业务运营者创造新业务形式打开了无限的空间和可能。

• 抗丢包能力强。一般来说，SD-RTN中可以针对用户网络使用更多的策略模型和技术，这样在30%丢包时，依然能够进行正常直播。而基于TCP的直播方案在丢包2%时就明显卡顿，达到30%经常已断开连接，无法进行直播。

• • CDN难点：连麦

直播中，主播如果要与用户交互，常见有两种方式：

• 第一种方式：文字，这种比较常见，实现也比较简单，这里不再进行分析；

• 第二种方式：连麦，这样主播可以面对面与观众进行交互，增加了互动性；

由于连麦方式比较复杂，这里进行详细分析。

1. 多路RTMP流实现

前面提到，RTMP是目前主播中最常用的协议，使用RTMP协议，可以实现最简单的一种连麦方式，如下图。

image

当有连麦者时，则主播端和连麦者端，都分别推一路RTMP流到CDN，CDN再将这两路RTMP流发送给观众端，观众端将两路RTMP流合成为一个画面。这种方式的优点是实现简单，但缺点比较多：

• 主播与连麦者如果要进行交互，则考虑到上面分析的延时问题，在这里延时需要至少加大一倍，这样对于实时交互来说，完全无法接受；

• 主播与连麦者交互时，声音会产生干扰，形成回音；

• 观众端要接收两条视频流，带宽、流量消耗过大，并且两路视频流解码播放，耗费CPU等资源也非常多；

这样看来，这种方式弊大于利，基本不可取。

2. 主播端与连麦者P2P

第二种方式，是主播端与连麦者之间使用P2P方式进行交互，然后主播端将自己和连麦者的视频进行合并，再推到CDN上，CDN再发送给观众端，如下图：

image

这种方式的优点有两个，一是主播和连麦者之间使用P2P，网络质量较好，延迟较小，保证了两者之间交互不会有非常大的延时；二是可以解决声音的干扰问题，消除回声。缺点是：

• P2P在某些网络下无法穿透，有些观众根本无法与主播端进行交互；

• 主播端需要上传两路视频：一路P2P与连麦者进行交互，一路使用RTMP推到CDN。还要下载一路视频：连麦者P2P发送过来的交互数据。所以主播端要求带宽需要较高，网络较差时无法进行主播；

• 主播端要进行多路视频的编码、解码，要求主播端设备配置比较高，较差的设备也无法进行主播；

• 只能支持一个连麦者，不能支持多个连麦者；

• 由于主播端和连麦者经过CDN合并成一路，因此，不能实现主播端和连麦者视频大小窗口切换。

综合来说，P2P方式在一定程度上可以解决连麦的问题。

3. 服务器端合图

另外一种方式，是主播和连麦者都将视频推送到CDN中，然后CDN内部对这几路视频进行合图，再将其发送给观众端。如下图：

image

这种方式的优缺点如下：

优点

• 主播和连麦者各路视频都使用RTMP推送到CDN，可以保证延时较小；

• 由于CDN进行视频合图和发送，所以主播不需要很高的带宽；

• 由于CDN进行视频合图，所以主播的设备不需要配置非常高；

• 没有声音干扰问题；

• 可以支持多个连麦者连麦；

缺点

• CDN需要进行视频的合图，需要额外开发工作，并且逻辑比较复杂；

• CDN需要进行视频的合图，需要消耗较高服务器资源；

• CDN合图后的布局难控制；

• 据目前所知，还没有CDN支持这种方案；

解决方案

使用前文中提到的SD-RTN方案，由于其延迟较低，主播和观众可以通过音频实时交互，而不会感到延迟过大而不自然。使用SD-RTN，可以很好的解决多路RTMP、P2P连麦、服务器端合图这几种方案的弱势，并且开发难度降低，合图布局等都可以很好的在客户端上进行控制。

具体SD-RTN的架构可以参考下图：

image

客户端均通过UDP连接SD-RTN架构服务，通过SD-RTN的就近接入策略，让使用者就近接入质量最好的数据节点，经过传输延迟和质量优化的最优路径，自动避免网络拥塞和骨干网络故障的影响，将数据发送给其他客户端。若有常规的长延迟旁路直播，则可以将主播与连麦者合成一路直播流，通过RTMP推到CDN，进行下发。连接这一路的观众，不能参与连麦互动，达到了最佳直播效果。
CDN部分文章摘自：https://mp.weixin.qq.com/s?__biz=MzI4MTY5NTk4Ng==&mid=2247489552&idx=1&sn=5c828588202090f214d467c8bb7584f1&chksm=eba41b8ddcd3929b1ef44a0d2fe62ea8267643177df6c50ceeeb512e4e7865afc303b35c1de1&m