浅谈实时音视频直播中直接影响用户体验的几项关键技术指标

前言

这两年互联网领域的一个热门关键词就是实时音视频直播，从刚开始的游戏直播和秀场娱乐开始，实时音视频直播带来了远超传统互动的用户体验，现在实时音视频直播已逐渐深入当今主流的互联网应用形态里。

本文将聊一聊实时音视频直播的几个关键技术：

• 清晰度：
  4K、1080p、720p，这些概念被各大电视机厂商炒作了这么多年，已经地球人都懂了。4K在互联网视频直播里现在还不普及，主要是对网络数据传输要求太高了。1080p在一些对清晰度要求较高的场景如游戏直播里已经慢慢普及，要求的数据传输速率大约在4Mbps左右。720p是现在直播的主流清晰度，速率大约在1Mbps左右。在一些要求不太高的领域，还会有540p或者360p出现。
• 流畅度：
  如果在直播时出现卡顿、转圈，就意味着不流畅。主播和观众的连接通道好比一根水管，流量是有限的，因此如果清晰度提升意味着观众收看直播的流畅度有可能会下降。
• 延时：
  视频直播都是讲求互动性的，如果跟秀场妹妹聊天，讲了半天都没反应就略坑爹了。但是延时也不全是坏处，适当的延迟意味着在观众端能够有一定的视频流数据缓存，当出现网络不稳定时能够抵御小范围波动而使得观众无感知。
• 首屏时间：
  当观众进入直播间算起，到出现第一个主播画面的时间叫做首屏时间。为了保证直播流畅，会缓存一段数据之后再开始播放，但这个也不是绝对的，后文会详细描述。
  

下面，我们将逐一分析和总结实时音视频直播中的这几个重要技术指标。

首屏秒开

先从观众进入直播间那一刻说起，这相当于整个直播生命周期的开始。当进入直播间后，播放器会向CDN请求数据。此时，假设主播已经发送视频流数据到了第100帧，由于数据传输的一些延时，CDN端最新收到的数据可能在第90帧。当CDN接收到拉取视频流请求时，他会做一件非常有意思的事情，即往前回溯一段数据，在图中显示的是回溯2秒钟，那就到了视频流的第五帧。CDN会把第五帧开始往后的数据，通过RTMP或其他直播协议源源不断的发送到播放器。那为什么要往回2秒钟呢，这可能算是目前视频直播技术中一个比较有特点的技术优化，能用于很好地平衡流畅度和首屏秒开时间。具体运作机制我们接下来再看。

流畅播放

接下去发生的事情，很好地可以说明回退2秒的作用。因为CDN是从第5帧开始发送数据，之后的数据全部缓存在CDN服务器中，因此可以源源不断地把数据发送到客户端，图中显示了从第5帧到50帧之间的数据，全部缓存在播放器内存中。这部分数据可以用于有效的抵抗网络波动造成的影响。当然，这样做的一个缺点是播放器相比于主播，延迟时间增加了2秒。所以说，视频直播所做的事情，就是在延时和流畅度之间找到一个很好的平衡点。

网络拥塞

网络拥塞是互联网上最常见的一个情景，接下去讨论当发生网络拥塞时发生的情景。假设当观众播放到第150帧时，用户下行网络出现问题，如果播放器没有新的数据到来，必然会画面卡住并开始转菊花。而此时，主播端并不会感知到这个事情，主播还在正常推送视频流数据。在经过了大概4秒左右的卡顿后，观众端的网络恢复，数据又会源源不断从CDN流向播放器。在图中看到网络流畅时，播放器的缓存中已经存放了第280帧数据，此时当前画面是150帧。这会产生一个什么问题？因为播放器播放数据是按照每一帧的时间戳匀速播放，因此如果不做任何优化就意味着每经过一次卡顿，直播的延迟就会增加一段时间，而增加的时间和被卡住的时间是一致的。

延时追赶

经过刚刚的描述，大家一定已经明白了延时累加是一个必须解决的问题。因此，播放器还需要做的事情就是延时追赶。播放器必须要实时侦测缓存中数据的情况，一旦大于某一阈值就启动延时追赶。追赶的方式，可以是直接扔掉多余数据也可以采用快进方式。快进模式相对来说用户体验会好一些，不会产生明显跳跃，处理时要注意声音不要因为快进而产生尖刺。最后再提一下，延时追赶不能太激进，还是应该在缓存中留一段数据，用于缓解以后可能再次发生的网络拥塞。

小结

前文描述了首屏启动、流畅播放、网络拥塞、延时追赶的基本概念和每个阶段内部所发生的事情，整个直播就在流畅、拥塞和延时追赶三个阶段中来回往复。看完本文，有兴趣读者可以尝试利用开源软件自己去写个直播APP，可以拿来练手娱乐，如果要上线还有各种其他奇葩的坑。

（原文链接：点此进入）

附录：更多实时音视频技术文章

[1] 开源实时音视频技术WebRTC的文章：
《开源实时音视频技术WebRTC的现状》
《简述开源实时音视频技术WebRTC的优缺点》
《访谈WebRTC标准之父：WebRTC的过去、现在和未来》
《良心分享：WebRTC 零基础开发者教程（中文）[附件下载]》
《WebRTC实时音视频技术的整体架构介绍》
《新手入门：到底什么是WebRTC服务器，以及它是如何联接通话的？》
《WebRTC实时音视频技术基础：基本架构和协议栈》
《浅谈开发实时视频直播平台的技术要点》
《[观点] WebRTC应该选择H.264视频编码的四大理由》
《基于开源WebRTC开发实时音视频靠谱吗？第3方SDK有哪些？》
《开源实时音视频技术WebRTC中RTP/RTCP数据传输协议的应用》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《实时通信RTC技术栈之：视频编解码》
《开源实时音视频技术WebRTC在Windows下的简明编译教程》
《网页端实时音视频技术WebRTC：看起来很美，但离生产应用还有多少坑要填？》
>> 更多同类文章 ……

[2] 实时音视频开发的其它精华资料：
《专访微信视频技术负责人：微信实时视频聊天技术的演进》
《实时语音聊天中的音频处理与编码压缩技术简述》
《网易视频云技术分享：音频处理与压缩技术快速入门》
《学习RFC3550：RTP/RTCP实时传输协议基础知识》
《基于RTMP数据传输协议的实时流媒体技术研究（论文全文）》
《声网架构师谈实时音视频云的实现难点(视频采访)》
《浅谈开发实时视频直播平台的技术要点》
《还在靠“喂喂喂”测试实时语音通话质量？本文教你科学的评测方法！》
《实现延迟低于500毫秒的1080P实时音视频直播的实践分享》
《移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡》
《如何用最简单的方法测试你的实时音视频方案》
《技术揭秘：支持百万级粉丝互动的Facebook实时视频直播》
《简述实时音视频聊天中端到端加密（E2EE）的工作原理》
《移动端实时音视频直播技术详解（一）：开篇》
《移动端实时音视频直播技术详解（二）：采集》
《移动端实时音视频直播技术详解（三）：处理》
《移动端实时音视频直播技术详解（四）：编码和封装》
《移动端实时音视频直播技术详解（五）：推流和传输》
《移动端实时音视频直播技术详解（六）：延迟优化》
《理论联系实际：实现一个简单地基于HTML5的实时视频直播》
《IM实时音视频聊天时的回声消除技术详解》
《浅谈实时音视频直播中直接影响用户体验的几项关键技术指标》
《如何优化传输机制来实现实时音视频的超低延迟？》
《首次披露：快手是如何做到百万观众同场看直播仍能秒开且不卡顿的？》
《Android直播入门实践：动手搭建一套简单的直播系统》
《网易云信实时视频直播在TCP数据传输层的一些优化思路》
《实时音视频聊天技术分享：面向不可靠网络的抗丢包编解码器》
>> 更多同类文章 ……

赞

通俗易懂

引用：子不语今安在 发表于 2018-06-07 12:05
通俗易懂

你这两天在论坛学的high吧

怎么了，不让看不让学？

引用：子不语今安在 发表于 2018-06-07 14:16
怎么了，不让看不让学？

那倒不是，只看你劲头这么足，要么涨工资，要么换新工作了吧

引用：JackJiang 发表于 2018-06-07 14:34
那倒不是，只看你劲头这么足，要么涨工资，要么换新工作了吧

哈哈，经验丰富啊，最近在交接，手头没有紧急事情，所以来看看，你这边东西比较系统，有利于形成宏观概念，还能帮助自己定计划，确实很感谢！

引用：子不语今安在 发表于 2018-06-07 14:44
哈哈，经验丰富啊，最近在交接，手头没有紧急事情，所以来看看，你这边东西比较系统，有利于形成宏观概念 ...

通俗易懂

引用：kbenh 发表于 2018-07-20 16:57
通俗易懂

别在刷贴了，你要多少积分，我送给你

必须赞一下，讲的太清楚了！