从 2008 年起 PC 互联网 / 移动互联网环境直播的发展概况
直播行业发展过程中有关技术部分的迭代包含了 5 个维度：音视频编码的迭代、音视频传输协议的迭代、音视频封装的迭代、音视频传输质量优化策略的迭代以及平台功能的迭代。
视频编码标准中应用最广泛的依然是 H.264、HEVC 以及 AV1。
音频编码标准从十年前单向直播领域的 MP3 发展为现在大范围应用的复杂音乐内容压缩编码标准的 AAC。
会议直播从 G.711、G.729 音频编码标准发展到更优秀的语音通话实时编码与处理标准 Opus，再到谷歌刚刚发布的 Lyra。
音视频编码的迭代给我们提供了更多的选择，能够在保证清晰度的前提下占用更少的空间。而音视频传输协议的迭代带给我们的则是更低的延时。
国内直播目前还是以 RTMP、HTTP 传输协议为主，为了降低延迟，主要采用 DNS 协议调度，并额外增加了 HTTPDNS 与私有化的协议解析域名进行调度，从而解决运营商的内容和流量劫持问题。之所以 RTMP 和 HTTP 会成为主流选择，主要还是因为传输协议比较通用，CDN 厂商支持比较健全。除 RTMP 与 HTTP 外，还有一些介于封装和传输协议之间较为模糊的标准，如 HLS 和 DASH。
谷歌的 WebRTC 大规模应用之前，很多直播会议采用的是类似 RTSP+RTCP+RTP 或者 H.323/SIP+RTP 的方案，视频采集与播放均需要客户端开发解决，无法直接在 Web 浏览器中使用，因而门槛较高。
在 WebRTC 大规模应用后，应用视频会议技术的直播平台逐渐增多，只不过这些平台中大部分并不把它叫做直播会议，而是体现为连麦、PK 等互动直播形式。
FLV 封装格式在国内依然被大范围应用，随着 Flash Player 播放器在浏览器中停止更新，PC 直播平台也开始逐渐转向 HLS 与 DASH。但是 FLV 格式因为可以自行开发移动客户端的特性，在移动端仍有很大的用武之地。
HLS 与 DASH 采用的是 mpegts 与 fragment mp4 的子封装格式，虽然 HLS 与 DASH 也支持动态多码率切换，但是延迟较高。近期推出的 LLDASH 与 LLHLS 都改善了延迟的状况，但由于依然需要在关键帧处切片，高延时问题并没有得到很好地解决，反而还会带来额外的协议方面的开销。
音视频传输质量优化策略的迭代
2016 年，谷歌公布 BBR 网络传输优化算法并提供源代码以后，做 TCP 传输优化的专家越来越多，大量更优的网络传输质量优化算法随之出现。还有很多直播平台基于 UDP 在不断地做一些直播传输质量优化的尝试，例如使用 KCP 替代 TCP，再比如快手发布的 KTP 传输优化，都可以替代 TCP 传输来提升音视频传输质量。再后来，还有很多平台尝试用 QUIC 替代 TCP 传输，来提升音视频传输质量，降低音视频端到端的延迟。
为了降低直播卡顿率，各直播平台还在不断地优化传输协议，从 AppEx 到 BBR、KCP，再到 QUIC，整个行业投入了大量的精力对网络进行针对性地优化，专门处理丢包、拥塞、抖动、慢启动等常见的网络问题，也有越来越多的链路传输优化专家开始着手进行更多的探索与深入研究。
创新很容易被复制，在创意逐渐干涸后，比拼的关键点从音视频流媒体技术本身转变为音视频平台服务质量。这对直播平台提出了更高的要求和挑战，因为提升 QoS 与 QoE 需要的不单单是音视频技术，还包括大数据、弹性计算、深度学习等。通过大数据可以及时发现用户体验的好坏，通过弹性计算可以实时调整相关服务，而通过深度学习则可以节省运维、运营成本。这些都需要大量的用户积累，长时间的技术投入以及深厚的技术功底，确保用户体验、降低卡顿率、提升清晰度、节省运维成本等工作也被纳入到直播技术中。
时至今日，要想提升服务质量，已经不单单需要功能的创新了。更重要的是要有大量的数据作为服务的支撑，以数据来驱动业务发展。如果没有健康的数据展现，我们所做的技术投入都有可能是徒劳，我们将无法准确评估 QoE、QoS 都是否得到了有效提升，也无法判断研发完成并投入使用的功能是否被大多数用户所喜爱。
参考资料：
原文链接：https://www.cnblogs.com/xyjk1002-rejuvenation/p/16668782.html
