直播简史

直播生态的演变

2010~2013

2010 年之前，直播技术的应用主要还集中在广播电视、广电 IPTV、安防视频监控、视频会议及个人媒体中心等领域，使用的传输协议主要为 MMS、RTSP、DVB-C、DVB-T、DVB-S 等。除了这些领域与协议，偶尔还会有一些场景采用 RTMP 与 HTTP+FLV 的方式做直播服务应用，例如一些广电领域的客户或优酷的重大活动直播等。但是当时 RTMP 与 HTTP+FLV 直播并未像后来这么火热，FMS、Wowza 等流媒体服务器还是当时的主流。

2010 年之后，随着 Adobe 开放了 RTMP 协议，CRTMPD、libRTMP、Red5 等支持 RTMP 协议的开源框架如雨后春笋般大量涌出，但是这些流媒体服务器还都需要再做一部分开发才能真正建立起服务端能力。2012 年夏天，Nginx RTMP 的出现打破了这场僵局，它通过大幅降低 RTMP 服务器的建设门槛，将 RTMP 协议的直播发展带入快车道。紧接着，2013 年秋天，Simple RTMP Server（SRS）的出现为 RTMP 服务器的建设带来了革命性的改变。并发展至今已经发布了 4.0 版本，SRS 采用了比较前卫的协程方式（用的 StateThread 做基础库）做任务控制，也可以理解为单进程、单线程的工作方式，不需要考虑信号量和锁操作相关的问题。如果想提升应对更高并发的能力，需要扩展多进程，借助第三方的工具来处理，例如 Docker，再例如自己启动多进程来控制多任务。SRS 原生支持的功能比较全，例如 RTMP 转 HTTP+FLV、转 HLS、转 WebRTC 等常用功能，运维操作方面支持 Reload，项目文档健全等。在互联网娱乐直播领域，由于 RTMP 可以保证从画面采集端至播放器端的整体延迟在 3s 左右，故而该协议被广泛应用。

与此同时，支持动态多码率的解决方案 HLS（HTTP Live Streaming）与 DASH（Dynamic Adaptive Streaming over HTTP）目前还在以草案的方式向前迭代，并未发布正式的参考标准，FFmpeg、GStreamer 等工具软件也在跟随着草案的更新进行功能迭代。当时，HLS 主要用于移动端与电视盒，DASH 也开始逐步被一些服务商采用，比如 YouTube、Vimeo、Akamai 等。同期动态多码率的解决方案除了 HLS 与 DASH 外，还有 Adobe 的 HDS（HTTP Dynamic Streaming）。由于 HDS 的参考标准并不像 HLS 和 DASH 那样由 RFC 或者 ITU 两个开放标准定制组织负责，而是 Adobe 自己在维护，所以推动起来并不是很顺畅，应用的客户也并不多。

2013~2015

从 2013 年开始，基于 RTMP 协议且主要呈现方式依赖于 Web 浏览器的直播平台开始逐渐发迹。它成为主流选择的原因有以下几点：

• Flash Player 能够直接播放基于 RTMP 协议传输的音视频数据；
• Web 浏览器已经默认内置 Flash Player 插件，不需要额外安装插件；
• RTMP 推流、播放有很多开源实现，能够快速搭建起端到端的解决方案。

相关技术的成熟导致 PC 端涌现出大量基于 Web 浏览器的视频秀场类直播、游戏类直播，以及部分户外直播。与此同时，移动端直播 App 也开始零零散散地出现。虽然安防监控、视频会议、广播电视与互联网行业也在使用直播技术，但其应用领域、方式、场景差异很大。安防监控方面，用户可以连接家用的监控摄像头，用手机观看家里的实时画面。视频会议厂商在 2013 年还在加紧兼容 WebRTC 框架以提升其通用性。H.323/SIP+RTP 的使用方案也比较普遍，因此当时做 RTC 的服务商与平台并不多。

2015 年，一个名为“17”的移动端 App 毫无征兆地成为了当时的爆款，但又迅速被 App Store 下架，自此事件开始，直播领域拉开了“千播大战”的序幕。各色各样的直播 App 被大力推广，底层的技术原理大同小异，推流协议仍然是 RTMP，拉流协议则以 RTMP 或 HTTP+FLV 为主，各家 App 主要差别在于起播时间、视频清晰度以及直播卡顿率。伴随着“千播大战”的开场，PC 端直播平台的用户流量开始逐渐被移动端的直播 App 所蚕食，直播平台的形态也渐渐分化。此时的直播应用主要集中在以下四大领域：

• 广电单向发布直播流，如 IPTV、电视盒，常用 HLS、DASH、HDS 这类端到端且画面延迟在 10s 左右的直播流媒体协议。
• 安防监控采集直播流，如海康、大华、水滴摄像头等，常用 H.323/SIP+RTP 等延迟在 50ms-500ms 左右的协议。
• 互联网/移动互联网互娱直播流，如秀场直播、游戏电竞直播、户外活动直播、街拍直播等，常用 RTMP、HTTP+FLV 等延迟在 3s 左右的直播协议。
• 视频会议直播流，如 Polycom、Cisco 等，常用 H.323/SIP+RTP 等协议。

2016~2018

随着时间的推进，直播场景也越来越复杂。2016 年，大量互娱直播平台逐渐增加了视频会议功能，也就是常说的“连麦”功能，使用场景也变得更复杂。实际上连麦采用的技术与视频会议几乎相同，但要兼顾互娱直播原有的场景，也就是一个直播间里，用户通过连麦进行实时交流，其他观众依然可以以原方式观看视频，例如歌曲合唱、实时采访、表演节目 PK、互相导入粉丝等，主播间也可以通过这种方式导入粉丝进行创收。当然，创新不仅止步于此，移动直播平台数量激增导致的“千播大战”让 2016 年被称为“直播元年”。

2017 年，大量的互娱直播平台又创新性地增加了主播与观众互动的能力，例如冲顶大会、在线答题等功能。另一面，直播创业的热潮开始消退，主要是由于用户流量再次向巨头靠拢，头部直播平台马太效应开始显现。随着流量的增加，巨头也不断进行技术迭代和升级，进一步提升了用户的直播观看体验，从而加深了自己的护城河。

2018 年，互联网/移动互联网直播开始逐渐从单纯的秀场、游戏、户外直播演变出直播带货场景。而当年的互联网直播巨头快手发布了实时交互性更强的直播 PK 功能，直播的形态从单纯的观看转为互动，又从互动转为挖掘用户需求。

从 2019 年至今，直播电商的市场规模达到了近万亿，在巨大的音视频互联网体量下，直播电商市场规模还能达到 100%以上的增长，说明音视频已经成为互联网行业非常重要的一项基础设施。甚至在快手平台，2019 年至 2020 年举办了很多次大型活动，从 2019 年的阅兵到春晚，在线数据一直在突破。快手春晚转播，最高在线人数创下纪录，达到了 2000 多万人；2020 年董明珠在快手直播卖货，一天卖了 3.1 个亿；周杰伦疫情期间从台湾连线，其跨海峡两岸的直播首秀，直播观看人数约 6800 万。

直播技术的迭代

自 2008 年 FLV 正式支持 H.264 开始，H.264 编码逐步被广泛应用，同期 VP6、VC-1、H.263、mpeg4video、mpeg2video 等编码方式同样比较火热，但后续只有 H.264 编码在国内脱颖而出。2013 年，PPLive 和迅雷率先公布采用 H.265（即 HEVC）进行视频压缩，在实现同等清晰度的情况下视频码率比 H.264 更低，引起了直播行业的普遍关注。随后各平台开始相继引入 HEVC 编码的视频直播流，但因为 HEVC 专利池问题的复杂性，又出现了一个比较诡异的情况：只有 Safari 浏览器支持 HEVC 的解码，而 Chrome 等浏览器却不支持，导致时至今日依然有大量直播平台还在使用 H.264 的视频编码。

除了 HEVC 在发展，谷歌同期还推出并迭代了 VP8、VP9 视频编码，主要应用于 YouTube 等海外视频平台，在国内并未被大规模采用。被大规模推广的 WebRTC 最初对 H.264 的支持不太友好，因此 VP9 才勉强得到了一定范围的应用。

2018 年之后，谷歌联合一众巨头共同组建了开放媒体联盟（Alliance for Open Media），并且推出了 AV1 视频编解码标准，且同样在 WebRTC 中被大范围应用。直到今天，视频编码标准中被最广泛应用的依然是 H.264、HEVC 以及 AV1。下一代视频编解码标准 VVC 已经正式发布，而 AV2 也在紧锣密鼓地制定中，业界很多企业也在用 AI 技术进行视频编解码方面的相关研究。相信在不久的将来，会出现更多优秀的视频编码标准。

而音频编码标准也随着时代的发展与应用场景的演变在不断迭代，从十年前单向直播领域的 MP3 发展为现在大范围应用的复杂音乐内容压缩编码标准的 AAC。视频会议直播场景下的音频编码标准则从十年前的 G.711、G.729 发展成更优秀的语音通话音频编码 Opus，以及谷歌刚刚发布的音频编码 Lyra。

总而言之，音视频编码标准原本处在大一统的时代。随着时间的推移，编解码人才逐年递增，数字信号处理专家也逐渐成长起来，更多人参与到了音视频标准的制定中。因而音视频编解码标准的发展随之进入了快车道，加上参与的公司与相关的组织也在逐年增加，最终用户和不同业务场景可以选择的音视频编码方案将会更加丰富。

低延时直播场景（延迟 3s 左右）

2010 年前，直播多采用 RTSP 传输协议，用户想要在浏览器中观看视频还要额外安装插件，所以多数用户选择在客户端观看直播。当 Adobe 的 RTMP 传输协议开放后，涌现出很多基于 RTMP 协议的框架，例如 LibRTMP、CRTMPD、Nginx RTMP、Simple RTMP Server（现已改名为 Simple RealTime Server）等，加上 OBS、FFmpeg 等客户端开源套件的出现，于是用户可以在 PC 端 Web 浏览器中直接使用默认安装的 Flash Player 插件来播放 RTMP 协议的直播内容，因而基于 RTMP 的应用开始广泛了起来，直播延迟也缩短至可以满足主播与观众的交流需求的范围。

随着用户对直播回看的需求的增加，行业对首屏指标的要求也逐渐提高，平台逐渐将播放协议从 RTMP 协议转变为 HTTP 协议，在建立连接时节省了很多 Handshake 相关操作。直播延迟的影响因素有很多，如果仅仅考虑合适的传输协议，通常只能勉强达到秒开的效果，但速度依然较慢，加之个别地区会出现域名劫持等现象，低延迟直播场景的需求仍然很难被满足。于是在域名解析方面，业界又做了一些优化，主要分为 DNS、HTTPDNS、私有化协议预解析域名三种，可以预先将用户调度至直播所属的服务节点，无需在用户发起请求时再进行域名解析，从而节省了域名解析时间，进一步降低直播延迟。

整体来看，国内直播目前还是以 RTMP、HTTP 传输协议为主，为了降低延迟，主要采用 DNS 协议调度，并额外增加了 HTTPDNS 与私有化的协议解析域名进行调度，从而解决运营商的内容和流量劫持问题。之所以 RTMP 和 HTTP 会成为主流选择，主要还是因为传输协议比较通用，CDN 厂商支持比较健全。除 RTMP 与 HTTP 外，还有一些介于封装和传输协议之间较为模糊的标准，如 HLS 和 DASH。

视频会议场景（延迟 50ms-500ms）

在谷歌的 WebRTC 大规模应用之前，很多直播会议采用的是类似 RTSP+RTCP+RTP 或者 H.323/SIP+RTP 的方案，视频采集与播放均需要客户端开发解决，无法直接在 Web 浏览器中使用，因而门槛较高。在 WebRTC 大规模应用后，应用视频会议技术的直播平台逐渐增多，只不过这些平台中大部分并不能称之为直播会议，而是体现为连麦、PK 等互动直播形式。

在互动直播出现前，大多数直播以秀场、竞技、体育等场景为主，主播与观众的交流方式主要是留言或者发送弹幕。互动直播出现后，诞生了在线抓娃娃、主播观众连麦交流等全新的互动方式，后来火爆全球的 Clubhouse 也采用了同样的技术。

视频封装的迭代

2010 年之前，直播流传输的通常是音视频的裸流，或者是常用的 MPEG-TS 直播流。在 Adobe 开放 RTMP 后，FLV 随即成为了广泛应用的直播流封装格式，该格式常见于秀场直播、游戏竞技类直播，在移动端直播也比较常见。

在支持 HEVC 方面，熊猫 TV 在 2017 年开始发起并联合多家公司共同定制了支持 HEVC 的 FLV 事实标准。目前 Adobe 并未对 FLV 参考标准作出任何更新，所以目前来看熊猫 TV 发起的这个标准在实际应用中不会出现任何问题。但如果 Adobe 突然有一天开始继续维护 FLV 并更新了 HEVC 的支持，就会出现比较大的风险，市面上大多数支持 HEVC 的 FLV 封装内容将无法播放。

在 PC 直播平台与移动端直播出现的早期，HLS 与 DASH 是同时存在的。HLS 与 DASH 采用的是 MPEG-TS 与 fragmented MP4 的子封装格式，虽然 HLS 与 DASH 也支持动态多码率切换，但是延迟较高。近期推出的 LLDASH 与 LLHLS 都改善了延迟的状况，但还需要在关键帧处切片，因而高延时问题并没有被很好地解决，反而会带来额外的协议方面的开销。

时至今日，FLV 封装格式在国内依然被大范围应用，随着 Flash Player 播放器在浏览器中停止更新，PC 直播平台也开始逐渐转向 HLS 与 DASH。但是 FLV 格式在移动端仍有很大用武之地。

两年前，快手自研了一套动态多码率自适应切换清晰度的技术（LAS，Live Adaptive Streaming），并于 2020 年开源。开源前该技术已经在快手大规模平稳运行多年，解决了 HLS 的高延迟问题，同时也解决了 RTMP 和 HTTP+FLV 的直播过程因网络质量变化，而不能自动动态切换清晰度导致的直播卡顿率高等问题。

视频封装的迭代还在不断演进，而且愈加丰富。单从 FFmpeg 的 Formats 格式支持来看，十年间发展了不计其数的封装格式。由于环境差异，国内外侧重使用的封装技术略有差别，国内还是以 FLV 为主，其次是 HLS/DASH 及其衍生的封装格式，还有已经形成实际使用标准且有数亿用户的 LAS。随着时间的推移，相信视频封装格式的演变将会越来越倾向于满足特定的业务与场景需求。

音视频传输质量优化策略的迭代

在移动网络处于 2.5G 向 3G 升级的年代，移动端直播主要还是以 HLS、RTSP 传输为主，由于当时的网络基础建设并不太适合高清视频传输，再加上视频采集与编码设备能力较弱，所以直播清晰度普遍较低，且直播链路会出现卡顿等问题。在之后的 4-5 年，也就是 3G 向 4G 升级的时代，直播方主要是以自研 TCP 优化方案或者采用 AppEx 的 TCP 优化方案来保证视频内容的传输质量。

2016 年谷歌公布 BBR 网络传输优化算法并提供源代码以后，做 TCP 传输优化的专家越来越多，大量更优的网络传输质量优化算法随之出现。

还有很多直播平台在不断尝试基于 UDP 做一些直播传输质量优化。例如基于 KCP 替代 TCP，再比如快手发布的 KTP 传输优化，都可以替代 TCP 传输来提升音视频传输质量。再后来，还有很多平台尝试用 QUIC 替代 TCP 传输的方式来提升音视频传输质量，降低音视频端到端的延迟。

对于主播推流端遇到弱网或网络上行质量较差的情况，各家平台也加大投入进行弱网服务质量的保障，例如在直播推流时做动态切换帧率、动态切换码率、降低分辨率等操作，确保主播端推流不会卡顿，但是这种做法又加大了服务端做录制兼容、转码兼容等处理的难度，这些问题都在努力解决中。

为了降低直播卡顿率，各直播平台还在不断地优化传输协议，从 AppEx 到 BBR、KCP，再到 QUIC，整个行业投入了大量的精力对网络进行针对性优化，专门处理丢包、拥塞、抖动、慢启动等常见的网络问题，也有越来越多的链路传输优化专家开始着手进行更多的探索与深入的研究。