直播优化方案

[如果觉得文章有用，可以支持一下放眼直播]

• 播放端优化
  • 实时性

  a. 丢帧和重连 
处理方式：丢帧的判断条件是：收流超过3s就启动丢帧，
（如果后续网络条件改善后，也可以缩小，这样就更实时，
如果网络很好而且稳定后，可以考虑不要缓冲区），
尽量是跳帧而不是加速。

参考我写的链接：ijkplayer丢帧的处理方案

• 流畅性

  a. 保证实时性的同时，将缓冲区由默认的5s，调整到3s

• 清晰度

   a. 使用ffmpeg软解的话，需要调整一个解码参数skip loop filter, 
    对应的ijkplayer的设置:
      [options setCodecOptionIntValue:IJK_AVDISCARD_DEFAULT forKey:@"skip_loop_filter"];

    环路滤波简言之：
    a:环路滤波器可以保证不同水平的图像质量。
    b:环路滤波器更能增加视频流的主客观质量，同时降低解码器的复杂度。

    具体参考：
    http://blog.csdn.net/h514434485/article/details/52241778
    http://www.cnblogs.com/TaigaCon/p/5500110.html
    这样清晰度基本和硬解等同。

• 性能

  a. 使用软解。 因为软解更稳定，虽然开销比硬解略大一点，
基本可以忽略；硬解的话，切换视频会关开一次，
导致黑屏或者闪屏，而且Android端硬解兼容性不好。

• 采集端优化
  • 实时性

a. 丢帧： 主播因为自身网速不足，或者节点不足，
到这编码后的数据推不上去，这时候需要丢帧，
（丢帧主要是通过缓冲区的数据，换算成秒，然后判断视频关键帧，避免花屏）。
b. 长时间低网速推流：这时候推流会积压很多数据，
即使丢帧也无济于事，因为再恢复之后，可能还是卡顿，
音视频不同步。这时候的策略是重连，当丢帧达到一定的次数，就要重连。

• 流畅性

  a. 推流重连之后，流畅性会提高，
可以避免长时间低网速下恢复后音视频推流的不同步
（这个原因是因为音频数据小，如果缓冲区过大，这时候推上去肯定是音频会比视频更快推完引起）。
  b. iOS视频编码用硬编，音频用软编32K
（音频硬编只能支持96K及以上，这理论可以节省16K， 
实际上看统计修改后也是8KB/s: (音频50多个包，每个包100个字节））
根据视频变化情况，这样推流的视频帧37-67KB/s之间, 音频是8KB/s， 总计45-75KB/s之间

• 清晰度

码率：655 ， iOS没有启动动态码率： 因为重连的机制，造成不稳定引起崩溃（动态码率我暂时屏蔽了）。
帧率：15
分辨率： 368*640（竖屏）

• 性能

a. 预览分辨率. 
iOS预览的时候：需要兼容低配手机. 默认是720P的预览，但是iPhone4/4s 和 iPad2最高只能480P。
b. 编码.
视频用系统硬编videotoolbox.开销最小。

---

一些关键问题的解决（含待发现和待解决的）

• 推流卡顿

  1. 节点问题引起
  解决方法： 
    a: 增加节点。
    b: 尽量分配同省同运营商。（目前网宿的机制已经调整成这样，个别不一致，
        网宿回复是他们的节点映射方案就是如此）
    c: 每次推流都请求最优节点。（目前的机制已经调整成这样）

  2. 手机性能原因
    主要是千元以下的Android机，尤其是mtk方案（比如红米），
    还有iphone 4/4s，cpu和内存还有存储都可能是瓶颈，导致推流太久的时候，容易推不上流或者卡顿。

  3. 应用在某些场景cpu和内存开销过大(这块具体有没有还不清楚)

  4. 推流器的继续优化，主要是弱网和波动情况，网络频繁变换情况下的异常处理。

• 播放卡顿

  1. 观众节点问题引起
  解决方法： 
    a: 增加节点。
    b: 每次播放都请求最优节点。（目前app的机制已经调整是这样）

  2. 手机性能原因
    主要是千元以下的Android机，尤其是mtk方案（比如红米），
    还有iphone 4/4s，cpu和内存和耗电量，导致播放太久的时候，容易卡顿。

  3. 应用在某些场景cpu和内存开销过大， 比如连击，可能有优化空间。

  4. 推流器的继续优化，主要是弱网和波动情况，网络频繁变换情况下的异常处理。

• 流媒体服务器（eg. 网宿）的推拉流的超时时间最好一致。

不一致的话，会引起一个小bug：
比如设置推流超时是30s， 拉流是20s的话（我们目前就是这样的设置），
主播25秒的时候没推上数据，那么播放端这时候已经结束了，
但是主播后面又恢复了，这样观看端如果有AB两个用户，
那他们可能一个在看，一个已经结束了。
（和网宿协商，但前提是先改客户端的超时和策略，再让网宿调整）。

• 推流端（主播）容易掉的问题。

  1. 将推流的超时（网宿默认是30s）增大。
（近期咨询过别的平台，有的是1-2分钟，后续和网宿再协商）
  2. 推流的重连次数增加。（目前app设置是重连3次，间隔3秒），
可以改成7次或者更大。（这块改动比较简单，后续和app端协商具体的值）
  3. 网络阻塞的时候也重连（已添加）