申明
本站点所有文章，仅代表个人想法，不代表任何公司立场，所有数据都来自公开资料
转载请注明出处
本篇，我们一起来聊聊直播技术，刚开始接触这块发现有很多的“行话”和术语，对于一个架构师而言，无法统一语言的高效沟通是最痛苦的事情，意味着，你根本无法理解客户的语言，今天先自我扫盲一些关键知识点和基本场景理解。
直播和点播有什么不一样？
点播，是视频文件已经存储在那里，用户可以随时随地进行播放，播放器进度可以由客户控制，比如从头，从上次观看的时间点，快进播放等等；点播的平台很多，比如国内的爱奇艺，腾讯视频，国外的 Youtube，Netflix 等等；
直播，视频源是通常由一方比如主播实时发起，由于是实时进行，播放器是没有进度条的，直播流到最终客户侧传输可以是推流方式播放，也可以是拉流模式播放；我们接下来看看有哪些直播场景。
整个直播主要环节包括 采集，编码，推流，转码，分发，拉流，解码和渲染 这几块；
直播有哪些场景？
直播在今年突如其来的疫情期间，得到非常广泛的传播，无论是在家办公还是停课不停学都少不了直播技术；
你听过或参与过哪些直播形式？
- 直播卖货：比如口红一哥李佳琪的抖音直播
- 游戏直播：比如国内的斗鱼、虎牙，海外的 Twitch
- 赛事直播：比如 企鹅直播，爱奇艺的西甲、WTA 网球赛直播
- 泛娱乐直播：比如 B站的二次元，直播答题，YY
- 教育直播：最近大火的，老师变主播在线给孩子们直播上课，比如沪江的 CCTalk平台
- 在线会议：比如 腾讯会议，Zoom，Amazon Chime 等等
直播从最终用户体验来说，要做到观看流畅，无卡顿，如果有互动，则互动更要尽可能“实时”。
千头万绪，到底要权衡哪些方面？
根据 Twitch 首席研发工程师沈悦时老师的一篇公开演讲，所有的直播场景，主要权衡三方面内容：
- 可扩展性：同时承载的在线观众数量？
- 低延迟：比如视频发布到接收端看到，又比如对话实时互动，又比如弹幕互动等等都需要低延迟 （标注：本文后面所有“延迟“数据，指的是端到端的延迟，即从主播摄像到观众看得的时间）
- 高服务质量（QoE）：画面质量，这个在某些场景非常重要
任何直播场景都需要在三者之间找到一个最恰当的平衡,最终会影响直播平台的技术实现和运营维护成本。
比如游戏直播的场景，一个直播间同时参与在线的人数往往很多，一般比较火的网红同时观看人数会在 10万左右（Twitch 的数据），单位观众的接入成本不能太高（成本包括服务器资源消耗，流量，客户的带宽要求等等）这就要求可扩展性要很好；类似，教育直播，比如上海市教委最新通知的，中小学统一同时在线学习，一堂课容纳的在线学生也是跟网红聚集的在线人流差不多，三个指标中，首先要满足的就是可扩展性，否则，同学们都不一定能进的了在线课堂教室；同时，这类场景的服务质量还要求很高，不能总是低清和卡顿，而高服务质量会牺牲一定的延迟。
再比如在线视频会议，要满足对话级的自然互动程度，通常端到端的延迟要控制在 200 ~ 400毫秒以内，所以，三个指标上，服务质量上会有所牺牲，比如画质和卡顿率要求就没有那么高，而且常见的会议系统通常能容纳的同时在线人数也只能在 20 ~ 100人左右，牺牲可扩展性，给低延迟让路。
推流是什么鬼？
直播中的视频源需要从 PC 电脑或移动端发布到直播平台，就称为“推流”，也称为“发布”。
技术面来讲，目前基本上都是利用 RTMP（实时消息传输协议）进行“主播”端推流，RTMP 最初是由 Macromedia 为通过互联网在 Flash播放器与一个服务器之间传输流媒体音频、视频和数据而开发的协议。随着视频直播领域的兴起，也成为业内广泛使用的协议。
RTMP 推流有个显著的特点就是低延时且低扩展性；
- 推流工具：PC 上有开源的 OBS （Open Broadcaster Software）软件，或商业版的 xsplit；移动端通常每家直播平台都会提供相应的开发 SDK；
- 被直播平台广泛采用：比如 B 站，斗鱼，Twitch, Youtube 等等
RTMP 有几个变种：
- 标准协议工作在 TCP 之上，使用默认端口 1935
- RTMPT 封装在 HTTP 请求之中，可穿越防火墙
- RTMPS 类似 RTMPT，增加了 TLS/SSL 的安全功能，使用 HTTPS 连接
近几年由于基于 UDP 的协议比如 QUIC 或者 SRT 的发展，也有很多玩家尝试自主研发 RTPM over UDP 的方案，比如国内的 B站团队，就在研发和灰度上线基于 QUIC 的 RTMP 直播方案。
QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于 UDP 的低时延的互联网传输层协议，QUIC 可以兼容 HTTP 1.1或HTTP / 2，基于 UDP 的 QUIC 协议相对比 TCP/IP 来说，由于不需要握手机制，延迟大大降低（包括建立连接和丢包重传都有优化）。
SRT （安全可靠传输）协议，开源且基于 UDP，同时专为高效安全视频流而设计；目前无论是 QUIC 还是 SRT 协议规范都在进一步演进中，自主研发需要比较高的研发成本，且有一定的不确定性，比如 QUIC 在移动设备的支持不够好，等等。
直播流播放
这方面的技术选型最丰富，为了实现比较好的用户体验，有非常多的优化技术细节，不过目前主流玩家主要两个方向：
国际上
主流方向是基于 HTTP 动态自适应流技术（HTTP Adaptive Streaming - HAS），HAS 是一种流化和 HTTP 渐进式下载混合的媒体内容分发方法；
代表厂商有 Youtube/Twitch/Hulu/Amazon 等。
海外厂商采用的主流方案包括 Apple 的 HTTP Living Streaming（HLS) 和 国际标准 MPEG-DASH（Dynamic Adaptive Streaming over HTTP）简称 DASH；
无论 HLS 还是 DASH，都会将内容分解成一系列小型的基于 HTTP 的文件片段，每个片段包含很短的可播放内容，再提供一个 播放清单（playlist）给到播放器，播放器收到播放清单才会一层一层向源站请求；
除此之外，市场上还有一些 HAS 方案，比如企业出品的 Microsoft Smooth Streaming（MSS），Adobe 的 HTTP Dynamic Streaming（HDS），以及OPEN IPTV Forum 定义的 OIPF 规范；
优势：
- 高可扩展性，但高延迟
- 客户端通过 HTTP 短连接不断请求内容片段实现了直播流的播放
- CDN 友好，部署方便、快捷，具有良好的防火墙穿透能力; 由于可以通过内容分发网络进行缓存分发，极大降低直播平台的流量成本；
- 可以直接在 HTML 5中播放； HLS 在苹果生态完全支持，大部分 Android手机浏览器也非常给力；
核心指标
- 延迟：通常 10秒左右，可优化；Twitch 基于 HLS 的低延时互动直播技术可以将延迟中位数控制在 4.5 秒；
- 服务质量（QoS）：由于是小的切片，可以通过码率自适应播放（ABR）技术优化弱网下的观众体验，即客户端可以根据网络状况，设备能力和用户偏好，实现自适应的码率和QoE；有非常多的服务器端和客户端码率自适应的算法；
- 切片大小：Twitch 通常是两秒一个片段，Facebook 和 YouTube是一秒钟一片；
国内客户
典型代表 B站，快手，爱奇艺，虎牙等等，主要采用的实现方案包括 RTMP、HTTP-FLV、HLS/DASH 或者 自研基于 UDP 实现。通常一个平台有可能会支持多种直播播放方案，比如同时支持 RTMP 和 HLS 等等。
RTMP & HTTP-FLV 直播流播放
为什么把这两个放在一起来讲呢，因为他们都是 Adobe 公司的解决方案：
- 国内非常多的直播平台采用该这两种协议作为直播流播放解决方案；
- 都是低延迟，通常 2 ~ 5 秒，所以都是直播首选方案
- 视频封装的格式都是 FLV，传输的数据也都一样，都是 FLV 文件的 Tag
FLV（Flash Video） 由 Adobe 公司主推的一种视频格式，优化在网络上传输流媒体数据的一种容器，格式简单，整个 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 组成，不需要很大的媒体头部信息；在延迟表现和大规模并发方面都很成熟；
RTMP 在推流章节介绍过，该协议比较全面，也可以用来用在接受和播放直播流，采用 RTMP 的直播播放一个典型的特征是 绝大多数使用 Flash 作为播放器！
HTTP-FLV，即将音视频数据封装成 FLV，然后通过 HTTP 协议传输给客户端；HTTP-FLV 的原理是服务器在响应客户端 HTTP 请求时候，不返回 Content-length 字段给客户端，这样浏览器就会不会认为数据已经传完了，一直会接受数据，直到服务器和客户端断开；
相较于 RTMP 协议，HTTP-FLV 能够好的穿透防火墙，它是基于 HTTP/80 传输，有效避免被防火墙拦截；并且首开和延迟略低于 RTMP；
采用 RTMP/HTTP-FLV 作为直播流播放方案的话，从采集推流到源站再到用户侧的播放器是一条完整的主动式数据流，相对于国m际通用的 HAS 解决方案，有明显的优势：
- 低延迟
- 基于长连接，RTMP 基于 TCP 长连接；HTTP-FLV 基于 HTTP 长连接；
- HTTP-FLV 支持大并发，也就是可扩展性比较好；同时支持 302 跳转，便于灵活调度；
但，也不是没有缺点：
- 服务器端资源消耗高；HAS 方案是客户端主动拉进行播放，而且 CDN 友好，单服务器的用户密度高，也就是整体成本要低很多；据沈悦时老师的分享，RTMP 推流播放对于服务器端的资源消耗要远大于 HLS 的拉流方式，Twitch 的经验，单台同样配置的服务器用户密度是 1：5，Twitch 一开始也是采用 RTMP 推流播放，不过成本太高，因此改成了 HLS。
- 播放器方面，RTMP 支持 VLC/FlashPlayer 等，不支持 HTML5 直接播放，iOS 需要第三方解码器；HTTP-FLV 需要集成 SDK 比如 flv.js 才能实现 HTML 5的播放；
- 这两种方式在 码率自适应播放调优方面能做的有限，后来 Adobe 出品了 HTTP Dynamic Streaming（HDS）来适应 HAS 的技术潮流；
- HTTP-FLV 会在本地缓存流媒体资源，保密性不够好
自研私有解决方案
很多客户会针对性自研适合自身直播特点的解决方案，比如 Twitch 的直播，自建了全球适合直播的 CDN 网络，并优化了 HLS 协议实现中位 3-4秒的端到端延迟，由于优化了协议，因此播放器必须嵌入自研的 SDK 方能播放直播流。详情参考沈悦时老师的《基于HLS格式的低延时互动直播技术》
国内了解到的快手基于 UDP 自研了一套 KTP（Kuaishou Transmission Protocol） 协议，但由于自研协议 CDN 不支持，所以，KTP 目前根据公开资料只是加速推流以及连麦场景，直接跟快手机房 IDC 超低延迟通信；详情可参考快手多媒体传输算法优化实践
国内外 CDN 直播支持差异
国内广泛采用的 RTMP 和 HTTP-FLV 两种直播播放协议，大部分海外 CDN 厂商都不支持，本质上 不过由于 RTMP 和 HTTP-FLV 是基于 TCP或 HTTP的长连接，CDN 的内容缓存效果有限，对于这类直播流分发，最需要的是一个稳定的、大带宽以及 BGP 线路的全球客户触达的网络基础设施。
以 AWS Cloudfront 为例，该 CDN 本身支持 HLS/MSS/DASH/HDS/CMAF 直播分发，都是 HAS 技术；那对于 RTMP 和 HTTP-FLV 可以利用 AWS Global Accelerator来进行加速，该服务也是利用庞大、无拥塞的 AWS 全球的网络，支持 TCP 和 UDP 流量的应用，加速延迟敏感的直播应用；
再比如独立的国外 CDN 厂商，Akamai 也只支持基于 HTTP 的流媒体 (HLS/HDS/MSS/DASH/CMAF)解决方案；
当然海外很多客户也有选择自建 CDN 网络来支撑点直播业务，比如 Netflix 私有的 OpenConnect网络；比如 Twitch 自建的游戏直播 CDN 等等；
在回到国内，主流厂商的 CDN 拉流都支持 RTMP、HTTP-FLV 以及 HLS 协议；关于推流协议，基本都是 RTMP 推流外，部分还支持自研的 RTMP over QUIC 推流 SDK，比如腾讯云直播服务，七牛云等；
其他一些黑话
什么是连麦？
连麦其实就是原来主播的直播流中，同时加上多路粉丝的语音视频流，本质上已经脱离了我们通常所说的广播式短时延直播，而是类似视频会议这样的一种实时音视频通信；所以，连麦对扩展性要求不高，也就是同时连麦在线的人数不会太多，比如腾讯云直播 SDK 连麦人数就控制在 10人以内，但对延迟会更加敏感；
对话级语音视频互动，端到端的延迟上面章节提到过，最好在 200 ~ 400毫秒之间；由于要求超低延迟，常规可以利用 RTMP 流媒体协议来实现，或者通过优化的基于 UDP 的协议，因为具备更好的拥塞处理，以及快速建立连接的优势，比如 WebRTC，该协议是 Google的开源技术，降低了实时音视频开发的门槛；
什么是弹幕？
弹幕功能是 B站非常受欢迎的一种互动功能，用户的评论像子弹一样从屏幕中穿过，英文称为“Bullet screen” 或 ”bullet comments“，技术人一般用 ”danmaku“ 表示，实现可以参考 B站的GOIM架构，通常用 Web Socket 来实现相对低延迟的消息推送 （1s内）：
观看体验 QoE 主要影响因素？
QoE 就是观众看得爽，主要影响因素：
- 码率 Data Rate：通俗一点的理解就是取样率，影响视频体积大小，码率越大，文件体积也越大，其计算公式是文件体积=时间X码率/8，而且一般文件包含视频和音频，各自会采用不同的码率，文件的大小包含视频和音频的大小；
- 帧率 FPS(Frames Per Second)：每秒钟帧数(FPS)越多，所显示的动作就会越流畅，帧率越大，画面越流畅；帧率越小，画面越有跳动感。如果码率为变量，则帧率也会影响体积，帧率越高，每秒钟经过的画面越多，需要的码率也越高，体积也越大；普通视频直播帧率在 15fps ~ 25fps；
- 分辨率：影响图像大小，与图像大小成正比，比如 480p就是指 640 x 480 个像素点，720p指 1280x720分辨率；1080P 指1920x1080分辨率；
后记
直播越来越火，去年底跟公司媒体专家跟客户谈了一次转码，才发现以前太高估自己了，隔行如隔山，先总结一篇，把看到的资料理一理，期望也对你有所帮助。
诞生于 2019，遇见 2020。
感谢关注，欢迎动动手指标星和置顶；
这样就不会错过少但精彩的技术探讨、团队建设、案例分享！
每周至少一更，转发是对我的最大鼓励！
学习之路漫漫，走走停停，
偶有所感，随心所记，
言由心声，问心无愧！
从客户中来，到客户中去！
