电商直播解决方案调研 - 文章 - 开发者社区

名词解释

视频

通常我们所说的视频，是指连续的图象变化每秒超过 24 帧(Frame)画面以上时，根据视觉暂留原理，人眼无法辨别单幅的静态画面，看上去是平滑连续的视觉效果，这样连续的画面叫做视频。

媒体转码

是指将一段多媒体包括音频、视频或者其他的内容从一种编码格式转换成为另外一种编码格式

内容分发网络

就是大家常说的 CDN，这里主要包含流媒体服务器，负载均衡，路由重定向，视频转码，视频录制存储，防盗链，性能等相关技术内容。常见的 CDN 加速包括文件加速、点播、直播三种业务。最开始阿里云 CDN 是从文件加速开始，针对的主要是内部客户，如淘宝，它的图片非常多，支持的都是小文件加速。随着各 BU 的端产品衍生，逐渐会支持大的文件下载业务。等阿里云 CDN 正式作为产品上线商业化时候，开始支持点播业务。2015 年下半年，开始支持直播业务。

码率

数据传输时单位时间传送的数据位数，一般用的单位是 kbps 即千位每秒。通俗一点的理解就是取样率，单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件，但是文件体积与取样率是成正比的，所以几乎所有的编码格式重视的都是如何用最低的码率达到最少的失真。但是因为编码算法不一样，所以也不能用码率来统一衡量音质或者画质。

帧

是一段数据的组合，数据传输的基本单位。就是影像动画中最小单位的单幅影像画面，相当于电影胶片上的每一格镜头。一帧就是一副静止的画面，连续的帧就形成动画，如电视图像等。

帧率

Frames Per Second，每秒显示帧数（fps），帧率表示图形处理器处理图像时每秒钟能够更新的次数。高的帧率可以得到更流畅、更逼真的动画。

picture.image

音频帧一般可以独立解码，直播播放。而视频分为视频关键帧和非关键帧，关键帧可以独立解码渲染，播放器拿到后可以直接看到画面，一般 10K 以上甚至几十 K；其他非关键帧解码依赖于前面的一些视频帧，播放器会根据前面的帧和这一帧来解码产生画面，非关键帧一般大小是几 K 甚至不到 1K。对于播放器来说，服务器一般会从视频关键帧开始发送，这样才不会产生花屏。

对于节点上直播服务器存储的内容，如果是文件加速，节点上存储的内容很明确，就是文件数据, URL 不变的话文件数据内容也不变。但是对于直播来讲，传输的就是帧数据，缓存的也是不断变化的帧序列数据。

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

Real Time Streaming Protocol，实时流传输协议

该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。

RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

picture.image

H.264

H.264 是由 ITU-T 视频编码专家组和 ISO/IEC 动态图像专家组联合提出的高度压缩数字视频编解码器标准，使用优势如下：

可利用低于1Mbps的速度实现标清（分辨率在1280*720以下）数字图像传送。
与其它视频编码标准相比，在相同的带宽下提供更优秀的图像质量。

H.265

H.265 标准在现有的 H.264 视频编码标准基础上保留部分技术，并进行了优化。使用优势如下：

可利用1Mbps - 2Mbps的传输速度传送720P（分辨率1280*720）普通高清音视频传送。
改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。

直播概述

通常，视频直播常见两种形式是手机直播和游戏直播，手淘、陌陌、映客的典型的手机直播平台，游戏直播就是像斗鱼、全民 TV 等平台。其实对于播放端来讲，直播和点播都是向服务器获取视频数据，播放端对声音和画面进行播放的过程。从这个角度来讲，直播和点播区别并不大。

picture.image

直播和点播的区别

对于视频点播，用户在观看的时候，可以随时选择快进和回退，直播却不能。对于视频网站上的视频文件来讲，点播可以选择今天看或明天看，但是直播却不能选择时间，像每周末的联赛只在固定的时间播放。一些机顶盒提供回看的功能，也属于点播。

什么是直播

直播就是每一帧数据打上时序标签后进行流式传输的过程。发送端源源不断的采集音视频数据，经过编码、封包、推流、再经过分发网络进行扩散传播，播放端再源源不断地下载数据并按时序进行解码播放。如此就产生了边生产、边传输、边消费的直播过程。

视频直播整个流程主要分为几个关键阶段：视频采集、前处理、编码、推流、转码、分发、播放

picture.image

采集，是视频直播开始的第一个环节，用户可以通过不同的终端采集视频，也就是主播直播的过程。iOS 端适配性较好，采集起来比较简单。Android 端因为一直以来市面机型多版本复杂种种情况，加大了一个库适配所有硬件的难度，采集起来相对比较困难。PC 端则和摄像头驱动联系紧密，目前市面上最好的 PC 端源免费软件是 OBS。 PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。
前处理，业内有一种说法，80% 的主播没有美颜根本没法看。所以美颜已经是对视频源进行前处理的标配功能，除此之外还有水印、模糊特效等，针对不同的手机系统提供不同的处理库。
编码，编码时候我们需要处理的硬件兼容性问题和寻求码率和画质之前的平衡是最大的两个问题。iOS 系统硬件兼容性比较好，可以采用硬编，Android 系统则还是因为硬件机型问题，大多采用软编。
推流与转码，在数据传输的整个过程中从主播端到服务器端，再到边缘节点，以及从边缘节点到播放端。为了让采集端的流适配各个平台端不同协议，一般都会在服务端进行转码处理，将视频文件转成不同格式，支持 RTMP、HLS 和 FLV 等不同的协议。
分发，随着移动直播兴起和游戏直播的持续火热，网络直播平台支持高并发是理论上应该做到的，为了优化终端观看直播的体验，一般都会采用 CDN 进行内容分发加速，实现高并发等能力。
客户端播放，也就是解码和渲染，目前 iOS 端的播放兼容性较好，Android 的硬件解码和编码一样也存在兼容性问题。通常秒开、低延时等问题是需要在播放端来克服的。在实际中，大多数直播平台会接入多个视频云服务提供商，做拉流线路互备，视频集群也是可优化部分来提高直播流畅性与稳定性。

picture.image

直播全流程：

picture.image

业务功能及场景

以阿里云视频直播 CDN 服务为例：

主要有以下五个方向：

UGC 互动直播：不仅提供推流到播放的全套直播解决方案，而且集成成熟的互动解决方案，包括 IM，连麦等功能。例如：一直播、映客等直播互动平台。
电商直播：为电商直播提供全套直播解决方案，支持动态扩展的直播技术架构，无需担心直播促销涌入的峰值流量担忧。例如：手淘等电商直播平台。
体育赛事／大型综艺节目直播：为热门的赛事和综艺直播提供动态扩展的直播服务，通过 CDN 和 PCDN 的分发，用户无需为突然涌入的流量担忧。例如：CCTV5，等电视直播平台。
游戏直播：对游戏直播提供各种采集设备的接入，以及直播的录制功能，便于游戏直播平台提供点播服务。例如：全民，熊猫，等游戏直播平台。
在线教育／财经直播：提供直播鉴权、直播防盗链、URL 加密等功能，为教育、财经类的直播提供安全保障。例如：第一财经等财经平台和知图教育等教育类直播平台。

直播架构

从应用场景角度分析

我们的应用场景是电商直播

从系统角度分析

picture.image

媒体模块主要与技术相关，上文的直播流程部分有介绍，主要介绍下其他模块。

服务模块涉及用户体验，从用户方的收益一部分也来自于服务模块。系统需要完整的礼物，支付，运营，任务等系统，复杂度不亚于页游系统。

国内直播平台的营利模式决定：平台从打赏中抽成。礼物系统就成为平台的盈利方式。礼物系统是多数视频直播平台的标配。
在中国部分人有礼品消费的习惯。平台为用户主播设计多个等级、爵位等头衔。利用财富榜，家族榜，等级榜类拉动消费。
IM技术。IM即时通讯服务。包括聊天室、弹幕等。弹幕交互方式是很好的体验，偏年轻化，大量用户愿意通过弹幕互动。高峰时，弹幕消息量特别大，一是需要考虑到高峰时弹幕的实时性和高并发量，二是要在产品策略上作一些体验上的优化。
支付系统需要仔细处理各种异常，消费流水记录。
系统还需要在政策上作相应的考虑，例如国家规定所有直播必须打水印并存留15天以上。在内容审核方面，淫秽、暴力、犯罪、敏感问题的审核。在数据分析方面也需要相应的统计系统

管理模块包括客户端的设计与维护、后台数据库、后台控制系统。该部分根据直播平台的特性、定位设计相应的管理策略。具体技术上还包括缓存、分布式文件存储、消息队列，运维系统等等。

从进程角度分析

就视频直播服务器的一个进程上来讲，我们可以认为一个推流端和多个播放端是一种非常典型的发布和订阅的关系。从下图可以看到，主播完成发布动作，这条直播内容也就是这一路流推动到服务器，三个观众也就是订阅者，从服务器拉流，也就是用播放动作来完成推流。这种进程内部、节点之间的发布、订阅关系是一种级联的关系，CDN 的直播分发就是依靠这种模式构建。

picture.image

方向选择

从成本上讲，直播系统的水比较深，如果自建背后有着惊人的成本，所以我们采用三方云服务。这里又分两种情况：

在IaaS/PaaS基础上搭建直播平台

用现成的IaaS/PaaS服务去搭建，核心服务器组由云计算服务商提供，不需要题主去费心了，但系统、网络部署还是要去做的。另外，考虑到平台的体量和需要用到的CDN数量，这种情况下是可以跟云计算服务商谈谈价格，用相对优惠的价格购买核心服务器组和足够的CDN节点。阿里云、腾讯云等都属于这种情况。这个方案的门槛要求相对前面要低一些，但也要有一定的系统部署能力
App开发方面，通常云计算服务商会提供API和SDK，题主可以在此基础上进行开发。
需要多平台适配、App开发、测试等环节

在SaaS基础上搭建直播平台

SaaS类方案，简单地说就是买现成的服务，在这基础上增加功能或二次开发，这样一来，题主只需要跟SaaS服务商了解如何操作、讨论功能定制和开发，以及谈谈套餐、CDN节点的报价了。微吼、CC视频、保利威视等常见的视频服务都属于这种情况
需要多平台适配、App开发、测试等环节

总结来说：

自建不太实现
云厂商把服务和SDK都做好了，属于半成品，需要我们自己接入进入定制开发。成本上降低了，但开发周期不一定短，因为团队之前没有相关经验，技术门槛还是比较高的。主要工作量在产品设计、UI、SDK集成开发。
找直播解决方案提供商，提供一站式解决方案。这个方案的门槛要求更低，但功能上没有自由开发定制程度高，受限于提供商提供的功能。集成SAAS层的平台费用会比半成品要高一些，但省去了人力成本，缩短了工期。