直播简史
直播生态的演变
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，整个行业投入了大量的精力对网络进行针对性优化，专门处理丢包、拥塞、抖动、慢启动等常见的网络问题，也有越来越多的链路传输优化专家开始着手进行更多的探索与深入的研究。
