网易视频云：浅谈视频云直播：场景、技术及优化1.简介随着互联网视频化的发展，各类网络直播产品层出不穷，涌现出了秀场直播、游戏直播、教育直播、演唱会直播和监控直播等多个直播生态圈。

这些生态圈形成的背后，是视频直播相关技术的不断发展，例如互联网带宽的日益增加，视频压缩标准的日渐完善，视频云技术的出现等。

特别是视频云技术的出现，它降低了开发者的准入门槛，解决了视频企业的“三高”之痛，即技术门槛高、成本高、卡顿延时率高，为未来几年视频直播的大爆发奠定了坚实的技术基础。

所谓视频云直播技术，就是用云端模式，提供视频直播解决方案的技术，它涉及视频直播的各个环节，例如直播视频采样、编码、推流、转码、分发、拉流、解码和播放等。

使用Iaas、Paas和Saas三种形式，视频云直播能为各种场景的直播应用提供接口级服务、平台级服务和产品级服务。

依托视频云，直播开发者不在关心视频和网络的细节，他们只要把精力集中于产品应用层面即可。

未来，网络直播产品将会表现为如下一种形态：上层多样化的直播模式 + 下层组件化的视频云模式。

深入视频云直播内部，会发现其具有复杂化、多样化和组件化的特点。

所谓复杂化，是指音视频技术复杂和互联网环境复杂；所谓多样化，是指直播应用场景具有多样性；所谓组件化，是指直播技术各个环节的模块化和独立性。

在视频云直播中，技术主线永远是音视频流的输入、传输和输出。

但针对每一类直播场景，使用的具体技术和实现手段都不一样。

随着直播量级的变化，必须对视频云各个环节进行优化，以化解流量暴增带来的压力。

因此，视频云直播的构建是一项艰巨的任务。

接下来，本文将从场景、技术和优化三个角度，详细阐述视频云直播。

2.一对多直播场景考虑如下一种场景：一个主播者坐在电脑前，通过前置摄像头和麦克风，把自己的音视频信息输出到网络上，多人在各地通过互联网实时观看主播者的表演。

这就是经典的秀场直播。

这里存在几个关键点：一. 音视频传输；二. 实时；三. 一对多。

首先讲音视频传输，它又细分为三点：源端的音视频输出、网络端的流传输和播放端的音视频获取。

第一点音视频输出，首先必须收集主播的声音和图像，就是所谓的音视频采集；采集后的声音和图像，需要转换成字节码、混合并压缩，最后封装成某种音视频格式，就是所谓的音视频编码；编码后的音视频格式，还不能在网络传输，需要转换成某种码流，如RTMP，然后推送到网上，即上传码流到服务器，就是所谓的推流。

上述“采样-编码-推流”，构成了视频云直播端的核心功能。

第二点音视频码流的网络传输，把主播者的音视频流分发传输给所有观看者；对于无法适配源端码流的观看者，在网络端转换码流，使其也能正常观看。

上述“分发-转码”，构成了视频云服务端VDN(Video Delivery Network 视频分发网络)的核心功能。

第三点播放端的音视频获取，首先从网络获取合适的音视频码流，就是所谓的拉流；然后对流进行解析，其中的音视频格式进行解封，就是所谓的解码；最后提取出单独的音频和视频，进行播放。

上述“拉流-解码-播放”，构成了视频云播放端的核心功能。

因此，如图1所示，仅秀场直播场景的音视频传输，就涵盖了视频云三个核心点: 直播端、播放端和视频分发网络，实现技术门槛很高。

直播端播放端图1. 视频直播流程接着讲实时这一点，在直播场景中，延时性要求很高，基本不超过10秒。

因此，传统的文件上传/下载模式，对于直播不可行。

传统的内容分发网络(CDN)也不适用直播。

视频云必须开发独特的流分发网络，应对直播场景实时性。

同时，经典秀场直播无实时交互需求，延时性不要求1秒之内。

因此流媒体传输，一般选用基于TCP的RTMP协议，无需选择实现难度更大但延时更低的RTP类协议。

最后讲一对多模式，就是一人讲，多人听。

这是一种视频云直播最擅长解决的模式。

在互联网现实应用中，还有很多种其他模式，例如多对多模式，就是多人互动直播，即视频会议；二对多模式，就是两人互动，然后多人听，即连麦；一对一模式，就是两人视频互动，即实时视频聊天。

各种模式，由于实时性要求不同，参与人数不同，实现难度各不相同。

本文围绕的场景是一对多模式，该模式最常用。

3.直播关键技术如图2所示，视频云直播的总体框架分为三层：最上层是直播SDK、中间为API接口层、最下面为云端服务层。

各层都有一些关键技术点，例如直播SDK层主要包含直播端推流和播放端拉流两个关键技术；API接口层主要涉及安全控制这一关键技术；云端服务层主要涉及VDN流分发这一关键技术。

接下来，我们详细描述这些技术点。

SDK直播端播放端服务器端HTML5Flash windows Android ios RTMP 推流直播辅助（聊天室、白板、滤镜等)频道管理WEB 后台API 安全机制：1.访问控制；2.鉴权保护；3.推/拉流防盗链；4.私有频道加密云端录制数据统计频道管理回看云存储VDN(流分发、转码）图2. 视频云直播总框架3.1直播端/播放端直播端和播放端是视频云直播SDK 的核心。

直播端是直播应用的起点，负责采样、编码和推流。

播放端是直播应用的终点，负责拉流、解码和同步播放。

如图3所示，播放端的处理基本上是直播端的一个逆过程。

接下来，简单描述其中每个流程。

音频驱动/视频驱动/设备音频驱动/设备视频驱动/设备网络端播放端直播端图3. 视频云直播客户端流程采样直播SDK 从设备驱动获取音频采样数据和视频采样数据。

其中，音频采样数据一般采用PCM 格式、视频采样数据一般采用RGB 或YUV 格式。

音视频采样数据体积非常大，因此需要经过压缩处理，来降低数据量。

编码编码包含音频编码和视频编码。

其中，音频编码负责压缩音频采样；视频编码负责压缩视频采样。

常用的音频压缩编码算法有AAC、MP3、WMA等，其中AAC最常用。

常用的视频压缩编码算法有H.264，H.265和VP8，其中H.264最常用。

封装独立的音频压缩数据和视频压缩数据，需要经过封装处理，放到一个统一格式的文件中。

常用的分装格式有：MP4、TS、FLV、RMVB、AVI等，视频云中，常用的有MP4、TS和FLV。

推流分装后的音视频数据，还需要再次进行传输协议封装，变成流数据，用于网络传输。

常用的流传输协议有RTSP、RTMP、HLS等。

生成的音视频流数据，也称码流，首先放到流缓冲队列中，然后按照一定的Qos算法发送到网络端。

关于Qos，我们将在下文中描述。

自此，整个直播端的流程已描述完毕。

接下来，讲述播放端。

拉流拉流是推流的逆过程。

首先，从网络端获取码流，并把数据放到缓存队列。

然后，按照一定的速率，从缓存获取码流，解传输协议，获取其中分装数据。

解封解封装过程，从封装格式中提取音频压缩数据和视频压缩数据。

为封装过程的逆过程。

解码解码过程，各种从音频压缩数据和视频压缩数据中，提取原始数据。

由于编码算法一般为有损压缩算法，提取后的原始数据，并非原始采样数据，存在一定的信息丢失。

同步播放各种获取的音视频数据，必须经过同步处理，才能播放。

上述，就是直播音视频在客户端的整个流程，其技术基本分为两块：一块为传统音视频处理技术；第二块是码流处理技术。

传统音视频处理已经很成熟，作为视频云直播一般会选用通用框架实现这部分功能，例如ffmpeg、vlc、gstreamer等。

音视频处理中，唯一重点需要考虑的是视频编码选择。

在音视频流中，视频大小占据90%以上空间，视频编解码算法的好坏，直接决定直播码流大小，因此是视频云直播的一个性能瓶颈点。

当前，业界一般会选择H.264作为视频编解码算法。

接着讲码流处理。

码流处理就是音视频码流在客户端的处理和控制技术，主要包括码流算法实现和Qos服务。

常用的码流算法有RTSP和RTMP，其中RTSP 基于UDP或TCP，在视频会议领域广泛采用；RTMP基于TCP，在直播中广泛采用。

这些码流算法协议公开，存在各种版本的lib库，因此在客户端实现难度较小。

Qos服务是用来解决网络延迟和拥塞等问题的技术，通俗的讲就是用来解决网络不稳定的一项安全机制。

在直播场景中，Qos需要保证网络不稳定情况下，观看者仍能观看直播内容，基本无卡顿。

这需要客户端提供一系列的功能保证Qos，其中最主要的功能如下：一. 直播/播放两端设置缓存，使码流处理匀速，以避免播放抖动；二. 在播放端根据场景或网络情况，动态选择码率、帧率等参数；三. 选择一定的丢弃或重传算法，以应对网络极差情况；四. 按照一定的延时性/流畅性要求，选择缓存大小等。

Qos服务无固定算法，视频云根据特定的场景提供特定的Qos保证，需完全自主开发设计。

3.2流分发图4. 视频流分发网络视频云直播服务端的核心是流分发，由流分发网络VDN负责实现。

整个VDN 的框架如图4所示，包含：流媒体服务集群、边缘服务器集群、转码服务器集群和智能负载均衡系统。

与静态文件分发网络CDN类似，VDN系统分为中心和边缘两层，边缘层直接跟用户连接，中心层负责服务器间的内容转发。

边缘层的核心是边缘服务器，它部署于全国各地及横跨各大运营商，例如北上广、移动联通电信等。

负载均衡系统，根据用户的地理位置信息，就近选择边缘服务器，为用户提供推/拉流服务。

中心层的核心是流媒体服务集群，该集群接收来自边缘服务器的码流数据，并转发给需要该码流的其他边缘服务器。

同时，中心层也负责转码服务，例如把RTMP协议的码流转换为HLS/TS码率等。

负载均衡系统负责中心层和边缘层的路由。

整个VDN的设计非常复杂，本文不具体展开，接下来只是简单介绍一下上/下行加速、低延时设置等机制。

有兴趣的朋友可以查阅SRS （Simple Rtmp Server）开源文档，了解VDN详情。

上行加速上行推流加速，又称上行边缘加速。

客户端根据VDN智能路由系统，选择最近的边缘服务器。

然后，客户端推流到该服务器，边缘服务器把流转发给中心服务器。

由于上行推流和下行拉流可能在同一台服务器，因此上行边缘服务器只会做简单的代理转发，把流转发给中心服务器或上层。

下行加速下行拉流加速，又称下行边缘加速。

客户端首先向边缘服务器取流，边缘服务器存在流，则直接给用户；如果不存在流，就执行回源模式，向相应的中心服务器取流。

对于非原始格式流，则进行转码操作。

转码可在中心层，或边缘层执行。

低延时机制对于直播场景，特别是交互直播场景，需要低延时，一般为1-3秒。

对于RTMP流分发，可以通过如下几个机制来降低延时：一. 降低读/写合并时间；二. 降低GOP；三. 减少累计延时队列。

跟磁盘flush策略一样，VDN也通过一次性读/写几毫秒流数据，来提高吞吐量，但增加了延时性。

通过关闭读/写合并，或者降低读写合/并时间，可以降低延时性。

GOP是音视频术语，指两个I帧之间的时间距离。