⽂章⽬录
⼀、直播场景和技术分析
好吧，既然你们⾮要搞什么直播，我就开始写写直播吧，怪不得WebRTC是下⼀代关键技术，直播的⼀些业务页必须要⽤WebRTC来实现
1. 直播场景分析
秀场直播
这个不⽤说，在各个直播平台都存在的形式
游戏直播
像⽃鱼、虎⽛、战旗等直播平台都是⽐较典型的游戏直播平台，游戏直播对码率要求⽐较⾼，观看⼈数也多，所以它也是流量贡献最⼤的直播形式。
移动直播
移动直播是最近⼀两年⽐较⽕的直播形式，⽐较明显的特点就是推流和播放⽐较容易, 通过⼿机APP就可以进⾏直播，所以⼿机直播⼀般也是推流数最多的直播形式。 活动赛事直播
这类直播⼀般对交互要求不⾼，所以⼀般都是HLS播放形式，延迟相对其他都会多⼀些。
答题直播
新型直播形式，每场直播的时间不长，突发流量⽐较⾼。
2. 常见传输形式
HTTP-FLV 延时3~5s
RTMP 延时3~5s
HLS 延时10s+
3. 对于低延时的直播需求
3~5秒延时对于多数常见的直播形式⼀般问题不⼤, 基本上满⾜之前遇到的直播形式，但在某些场景下，直播的体验⾮常差，例如我们最常见的连麦，如果延时超过了1s，基本上整段垮掉
对于这种场景，现在⼀般的直播平台采取的⽅案⼀般是借助第三⽅的连麦服务，然后再推给CDN⼚商来加速视频传输的速度
在答题直播场景下, ⼀般都要求在⼀段时间内⽤户提交答案，如果有各别⽤户延迟⽐较⼤，这样对⽤户是不公平的。虽然直播平台仍然使⽤FLV的传输形式完成答题直播，但是基本都会采⽤SEI插帧等⽅法来解决时间同步问题, 需要平台的端和直播CDN做⼀些配合来完成。
除了连麦、答题场景之外，像在线课堂、在线拍卖等场景因为涉及到实时性的互动，对延时的要求也⽐较⾼。
从对业务的⽀持层⾯来看, 仅仅有RTMP、FLV这种3~5秒延时以上的直播形式已经不够了, 需要对更低延迟的直播业务进⾏⽀持。从技术的⾓度来看，国内常⽤的FLV、RTMP这种直播⼿段，本⾝是Adobe⾃⼰的标准, ⽽且很快会停⽌对Flash的维护, 另⼀⽅⾯WebRTC技术的兴起，Chrome、Safari等浏览器也都进⾏了⽀持，因此也需要对新的技术有⼀些调研和准备。
4. 短延时直播VS实时⾳视频通信
使⽤WebRTC主要⽤于解决实时⾳视频通话的需求，必然对延迟要求⾮常严格, ⼀个会议室中参与的多⽅可以进⾏视频通话, 每个参与者可以看到其他参与者，也能听到其他参与者说话。每个参与者既有推流，⼜有播放，数据是双向的。所以参与⼈数不会太多，⼀般不能超过20个。 遥控激光笔短延时直播仍然是直播业务类型, 只是延时⽐较低, 短延时直播的业务模型相对简单, 数据单向传输，⼀个主播推流，参与的播放者⼈数没有限制，上百万都可以。
5. 关于技术选型
关于技术的选型，我们需要兼顾各种各样的场景
1. 关于之前的业务的兼容
2. CDN实现直播的秒开，WebRTC在移动端拥塞控制和重传⽅⾯有⼀些处理，所以我们需要使⽤WebRTC解决卡顿的问题
3. 关于WebRTC，这个技术有点复杂，采⽤⼀部分功能
6. 为什么不选择TCP
已有的业务，⽆论是图⽚、⼤⼩⽂件、点播、直播，这些都是在TCP通信基础上实现的，所以短延时直播在开展的时候我们就思考了TCP的可能性。 我们对于短延时的⽬标定义为从端到端800毫秒以内，⼀场直播的延迟来⾃于推流端延迟、CDN产⽣的延迟、播放端延迟这三个⽅⾯，
从经验⾓度来看，播放端的延迟会⽐较严重，主要是两⽅⾯，⼀⽅⾯是开播时候卡前⼀个关键帧所带来的延迟，另⼀⽅⾯如果CDN服务器到播放端有抖动，累积的延迟会越来越多。
我们来看⼀下TCP，当⽹络抖动出现丢包的时候，TCP是ACK确认机制的，也就是发送⽅发送⼀包之后，⼀定要等过对⽅回应，才会继续发。如果说⽹络⼀旦出现丢包，就会在⼀个RTO之后重传，RTO的值和RTT有关，并且RTO的最⼩值是200ms。如果想保证流畅性，你的播放端⼀定要⾄少能容忍200ms以上的抖动，但播放端的jitbuffer太多⼜⽆法满⾜低延时的要求。
分子筛膜
⾥对⼀下⽐WebRTC中RTP传输使⽤的NACK机制，NACK的丢包反馈更加及时，如果⽹络是偶然性抖动居多的时候, NACK机制效果更加好。这⾥我们也做了⼀个统计，全⽹平均RTT⼩于15ms，如果CDN节点覆盖⾜够好的情况下，延迟理论上会很低。以1.5Mbps码率的⾳视频流举例，每秒钟100个包，包和包之间就是10ms的间隔。如果当第⼆个丢包出现的时候，第三个包对⽅接收到了，就可以马上知道第⼆个包是丢掉了，就可以⽴刻返回⼀个NACK，进⾏重传。在这种极限情况下，重传间隔就是25ms，相⽐之前TCP的200ms是⼀个质的提升，想满⾜绝⼤部分播放延迟在800ms以内才有可能。
另外，使⽤TCP的话，⽆效传输没法避免,。TCP是采⽤socket buffer进⾏通信，数据也是从应⽤层先进⼊socket buffer再分发。对于RTMP或FLV的分发来说，假如某⼀帧的数据的⼀部分已经进⼊了socket缓冲区, 那么也必须将这⼀帧剩余的数据发送出去, 如果剩余的数据不发出去的话, 播放端会出现解析错误, 断开连接, 这个体验会很差。
⼆、关于直播中问题和分析
直播常见的问题包括
主播在不稳定的⽹络环境下如何稳定推流？
偏远地区的观众如何⾼清流畅观看直播？
直播卡顿时如何智能切换线路？
如何精确度量直播质量指标并实时调整？
移动设备上不同的芯⽚平台如何⾼性能编码和渲染视频？
美颜等滤镜特效处理怎么做？
如何实现播放秒开？
成上上网如何保障直播持续播放流畅不卡顿？
1. 秒开问题
对于国内⼤部分平台都是使⽤的H.264和AAC，我们在这个基础上进⾏秒开的优化
对于RTMP流播放时出现⿊屏问题，我们⼀般的认识都是因为⽹络慢、⼿机性能差，那么就真的是这样的吗，下⾯我们⼀起来看看视频播放的时候发⽣了什么。
第⼀点：视频是如何播放的
对于H.264编码来说，我们会有三个不同的帧，所谓帧是什么呢?就是你看到的每⼀个图像。
我们看到动态的视频，⼤家知道电影最开始⽤胶⽚拍的时候，每秒是25帧，是每秒25个图⽚在切换。
对于H.264来讲，我们常见的有I帧，P帧，和B帧。
I帧
I-Frame也有⼈会叫Inter Frame，那么它的意义是什么?
它是⼀个⾃描述帧，你可以理解为它就类似⼀个jpg图⽚，它⾥头所有的数据，你解出来之后，它就是⼀整张图⽚。
⽆其他帧引⽤，它不需要去做前置和后置的引⽤。
它压缩⽐是最⼩的，因为它要包括整个图⽚所有的数据在⾥头。
P帧
P-Frame也就是说预测帧，它的预测帧是怎么回事呢？P帧就是保留变的部分，不变的部分你去上⼀个或者⼏个帧⾥⾯就⾏。
P帧的好处是什么呢？因为它只存⼀些变化信息，所以它⼤概的压缩⽐是I帧的50%。
B帧
针式吸盘B-Frame，前后双向引⽤预测。
B帧⽐较特别，它要引⽤前⾯P帧某⼀部分的图像数据同时B帧后⾯的数据也会引⽤，这个是B帧的特点，它要引⽤前⾯的数据，也要引⽤后⾯的数据。那么它的优势就是压缩⽐⽐P帧还⼤，⼤概是I帧的25%，也就是我们B帧⽤的特别多的话，它会把视频的⼤⼩降的⽐较低，因为它的压缩⽐更⼤⼀些。高杨氏
I帧，B帧，P帧它是怎么组成⼀个视频流呢?我们管这个东西叫Group Of Picture，简称叫GoP。
视频解码器，看到GoP它是怎么放呢?那很简单，编码器会有⼀个缓冲，然后它会保留从I帧开始，当然现在说是I帧，其实这个I帧还有个特殊的类型。从I帧开始，他会把数据缓存到解码器的Buffer⾥，当他遇到下⼀个P帧，或者再下⼀个B帧的时候，它会从它Buffer⾥到它之前引⽤的那个帧，然后把这个数据解出来，最终播放到显⽰器上。
压片机模具
IDR帧
IDR帧是I帧，但I帧并不⼀定是IDR帧，所谓IDR帧是什么?它就是拿到这个帧之后，播放器可以直接从这个帧开始往后播放，它保证后⾯的P 帧和B帧的引⽤不会跨越这个IDR帧，那么看到IDR帧，编码器就可以把当前的Buffer清空，从当前这IDR帧开始解码往Buffer⾥边放，后续帧就可以从Buffer⾥的数据引⽤，然后解码，也就是说编码器可以从任何⼀个IDR帧开始解码。⼤家可以联想到，当我播放⼀个视频⽂件的时候，我可以拖动，但是我拖动的任何⼀个点，它肯定是⼀个IDR帧，当然它也是I帧，但是并不⼀定说每⼀个I帧我都能让它作为⼀个拖动的点。
IDR帧有时也有它不太学术的叫法：关键帧。
IDR 图像之后的图像永远不会使⽤ IDR 之前的图像的数据来解码。
我们可能会看到FFmpeg的数据结构⾥会标着PTS和DTS，那么PTS和DTS是什么呢?
PTS和DTS是什么?
PTS，Presentation Time Stamp也就说这个帧什么时候会放在显⽰器上;
DTS就是Decode Time Stamp，就是说这个帧什么时候被放在编码器去解。
那么如果全是I帧和P帧，PTS和DTS都是单调递增的，那么如果我们有B帧，会出现什么情况?因为⼤家都知道，对于B帧来讲，它会引⽤前⾯的帧和后⾯的帧。
为什么直播会等待
对于直播来讲，它是⼀个流，它不像点播，⼤家都从0秒开始，任何⼀个视频⽂件，0秒第⼀个帧肯定
都是关键帧。那么对于直播来讲，我是⼀个随机的时间点接到这个视频流进⾏播放，那么我接⼊的这个时间点的帧有可能拿到的第⼀个帧的数据是I帧，也有可能是B帧，也有可能是P帧。这是⼀个随机的。在这种情况下，我们⼤概率会出现⼀个⿊屏的状态。因为我拿到的是个P帧，对于P帧来讲，解码器⾯那个Buffer是空的，它不知道这个P帧如何进⾏解码，所以它只能丢弃这个帧。
对于直播来讲，我⼀秒钟的帧数是固定的，只能等到我下⼀个关键帧到来的时候，我才能开始去播放。当然正好赶巧了的话，接⼊那瞬间得到的数据正好是个I帧。就可以达到秒开的效果。
关键帧缓冲如何⼯作
其实是在cache服务器上，它会去预先解⼀下这个帧，然后去看它到底是个I帧，还是个B帧，还是个P帧，当它发现是I帧的时候，它会放在它的程序的内存⾥头，当你每⼀次打开这个视频流的时候，cache服务器会把内存中的I帧发送给客户端⽐如当前播放到了P帧，那我把P帧前⾯的I帧和P帧全波放到cache的内存⾥，然后当客户端接⼊之后先把内存⾥的数据发送给客户端解码器，然后再从这个B帧往后给。对于这个解码器来讲，它很舒服，它接到第⼀个数据流的第⼀个包肯定是I帧，那么它就可以直接播放了。
2. 平滑发送机制
我们可采⽤混合拥塞算法，基于丢包率和基于延迟进⾏码率控制。标准的做法是，当播放卡顿时，会让发送端降码率。WebRTC已经帮我们做了这⼀部分的⼯作
3. 播放端的优化
⼀阶段是开播阶段，获得GOP数据的时候，如果端不做处理的话，⼀定会有⼀个延迟。所以在这个阶段，播放端⼀定进⾏快进的操作，缩短延迟。第⼆阶段是当⽹络出现抖动的时候，会慢慢放⼤buffer的长度，来⼀定程度上适应抖动，提⾼流畅度。第三阶段，当⽹络恢复的时候，我们可以适当快进，减⼩buffer，把进度赶回来。也就是说这个buffer⼤⼩是动态变化的。
4. FEC冗余传输
FEC是靠冗余传输，来提⾼容错率。关键帧10%冗余率, ⾮关键帧5%，根据丢包判断出⽹络状况，动态调整冗余度。
5. 探活策略
除了对于正常关闭进⾏主动通知之外, 还需要对超时情况进⾏处理。即便是TCP传输的时候也有类似的问题，推流端发送了FIN结束报⽂，但是服务器未必收到，所以⼀定要有超时的机制来进⾏管理。我们采⽤数据及时反馈的机制，在下⾏播放端要求周期性的返回⼼跳，上⾏要求推流端在8或10秒内
⼀定要有⼀些真实数据传输，否则我们就会断开。
参考链接
