直播视频秒开及视频优化

  视频容器封装 (Container)： MP4，MOV，FLV，RM，RMVB，AVI，…
  视频编码格式 ( Codec )：Video : H.264，H.265, …  ； Audio : AAC， HE-AAC, …
  1.ijkPlayer点播播放秒开，rtmp直播视频秒开？视频播放优化 视频秒开 首帧优化，弱网下视频播放优化？？
  2.点播秒开和直播秒开？视频秒开，“秒开”解决的是直播首次加载的播放体验。在手机直播场景下，这就是一个刚需。没有美颜功能的手机直播 APP，主播基本不爱用。

- 视频播放中可能有的bug:
 1.红蓝反色——YUV or YVU
 2.黑屏、大花屏——SPS、PPS数据错误
 3.绿屏——MX4，获取截屏宽未设置为32倍数
 4.局部花屏——丢帧
 5.不支持该手机——编码器参数
  几个对视频的质量和大小影响最大的参数：帧率、码率和分辨率。
  iOS 平台上无论硬编还是软编，由于是 Apple 一家公司出厂，几乎不存在因为芯片平台不同而导致的编码差异。
  然而，在 Android 平台上，Android Framework SDK 提供的 MediaCodec 编码器，在不同的芯片平台上，差异表现很大， 不同的厂家使用不同的芯片，而不同的芯片平台上 Android MediaCodec 表现略有差异，通常实现全平台兼容的成本不低。另外就是 Android MediaCodec 硬编层面的 H.264 编码画质参数是固定的 baseline，所以画质通常也一般。因此，在 Android 平台下，推荐是用软编，好处是画质可调控，兼容性也更好。
  直播是媒体流、APP 的交互是 API 信令流，两者的状态不能混为一谈。尤其是不能基于 APP 的交互的 API 状态来判断直播流的状态。

  视频优化有两大方向，编码效率优化和编码性能优化：前者追求同质量（同信噪比）下更低的码率，后者追求同样质量和码率的情况下，更快的编码速度。

  一个视频 ( Video ) ，其图像部分的数据是一组 GOP 的集合, 而单个 GOP 则是一组 I / P / B 帧图像的集合。

 直播优化那些事：卡顿优化；延时优化；数据代理优化；首屏秒开优化；弱网优化；运营商劫持优化；CDN节点优化。

 直播主要有以下几种类型：1、事件直播；2、泛娱乐直播；3、游戏直播；4、移动直播；5、户外直播；6、VR直播；7、教育直播。

  一个完整的直播过程，包括但不限于以下环节：采集、处理、编码、封包、推流、传输、转码、分发、拉流、解码、播放。

> 直播常见的问题包括：
 1.主播在不稳定的网络环境下如何稳定推流？
 2.偏远地区的观众如何高清流畅观看直播？
 3.直播卡顿时如何智能切换线路？
 4.如何精确度量直播质量指标并实时调整？
 5.移动设备上不同的芯片平台如何高性能编码和渲染视频？
 6.美颜等滤镜特效处理怎么做？
 7.如何实现播放秒开？
 8.如何保障直播持续播放流畅不卡顿？

  9.视频丢帧引入花屏？ 实现清晰度切换？ 视频倍速播放的问题？

> 直播疑难杂症排查- http://blog.51cto.com/ticktick/p1
 解决过各种形形色色的问题，如直播卡顿、马赛克、花屏、黑屏、杂音、音画不同步等。编码器最重要的五个参数：画质级别、码率、帧率、GOP 大小、码控方式。
 - 播放失败；- 直播卡顿；- 首开慢；- 延时高；- 音画不同步；- 马赛克严重；播放黑屏、花屏、绿屏；- 播放杂音、噪音、回声；- 拖动不准；- 发热问题；

 1.播放失败原因：域名解析失败；服务器连接失败；请求的资源不存在；不支持的格式；只有音频没有视频，或者只有视频没有音频
 2.直播出现卡顿，三个端都可能是问题的源头：
  - 主播端的网络不好，导致推流上行不稳定
  - 服务端的线路质量不好，导致分发不稳定
  - 观众端的网络不好，导致拉流下行不稳定
 3.首开：为了加快首开效果，需要对播放的缓冲策略做一些调整，如果第一帧还没有渲染出来的情况下，不要做任何缓冲，直接送入解码器解码播放，这样就可以保证没有任何因为 “主动” 缓冲带来的首开延时。从而加快首开，但是需要注意的是，设置地太小可能会导致读取的数据量不足，从而无法解析出码流信息，导致播放失败，或者出现只有音频没有视频，只有视频没有音频的问题。
 4.延时高：网络传输延时；业务代码中的缓冲区；协议延时；（解决直播延时问题，基于 udp 的私有协议来传输数据。）
 5.音画不同步：音画不同步问题，更多的时候，应该从生产端去排查原因。采集源距离太远；采集设备内部问题；时间戳没有在采集的时候获取 ；时间戳出现回退或者紊乱；播放端性能问题
 6.马赛克严重：视频编码参数配置原因； 图像尺寸原因；客观条件原因（光线暗的场景或者剧烈运动的画面场景）；关键帧丢失
 7.黑屏、花屏、闪屏问题
  a.播放黑屏：主播端摄像头权限问题；主播端编码失败；视频解码失败；码流的前半段只有音频没有视频
  b.播放花屏/绿屏：丢失参考帧导致的；播放器没有从关键帧开始解码；码流中视频尺寸发生变化；硬编硬解的兼容性问题；推流端图像尺寸和格式处理不当
  c.播放闪屏：播放器缓冲机制原因；推流端的原因
 8.播放杂音、噪音、回声问题：参数配置问题；代码层面的原因；网络波动；回声消除；混音越界
 9.拖动不准：关键帧间隔太大；直播丢帧
 10.直播功耗高：CPU/GPU 占用率高。数据量太大（减少视频的尺寸和帧率）；大量的格式转换；对图像进行放大操作；软编/软解
  - 人脸识别/美颜/滤镜，对 CPU/GPU 消耗很大
  - 代码逻辑中过多的 memory copy 操作
  - 后台线程频繁唤醒手机访问网络或者读写 SDCard
  - App 的一些动画特效等。

-- 决定视频预加载效果好坏由三因素决定：
 1.网速；2.缓冲文件大小；3.视频码率
 码率低、网速快的情况没必要使用预加载，码率中等、网速一般的情况合适使用。另外，缓冲文件也不能设置太大：过大的缓冲区会刷爆MediaPlayer内置的缓冲区，
影响正常播放；再者，读取缓冲文件也耗时。

-- 播放视频时,会停留在第一帧画面，一般来讲,这个现象有三种原因导致:
 1.没有接收到视频帧;
 2.解码器出错,只解出了第一帧图像;
 3.时间戳计算有误,导致长时间sleep;
 - 解决方案：
  a.那逐一排查下.首先在媒体帧回调的地方下个断点,发现的确有视频帧接收到,并且视频帧最终正常地push到解码的队列当中了,说明第一个假设不成立.
  b.其次,我们看看解码器,似乎也正常工作,没有打印任何异常信息.解码线程也并未退出.那也第二个原因也初步排除.
  c.第三步,重新播放下,跟进到解码线程里面.发现最终sleep时间大的惊人.解码线程解完首帧后就一直在睡眠状态了.再跟踪一次,发现是硬解码初始化失败了,自动切换到软解码,而在软解码完成首帧解码后,未把该帧的时间戳赋值给时间戳,这样实际上首帧时间戳为0了,后续视频帧的时间戳与首帧时间戳相隔太大.sleep时间也随之变得很大. 

--  iOS 平台上无论硬编还是软编，由于是 Apple 一家公司出厂，几乎不存在因为芯片平台不同而导致的编码差异。
然而，在 Android 平台上，Android Framework SDK 提供的 MediaCodec 编码器，在不同的芯片平台上，差异表现很大， 不同的厂家使用不同的芯片，而不同的芯片平台上 Android MediaCodec 表现略有差异，通常实现全平台兼容的成本不低。
  另外就是 Android MediaCodec 硬编层面的 H.264 编码画质参数是固定的 baseline，所以画质通常也一般。因此，在 Android 平台下，推荐是用软编，好处是画质可调控，兼容性也更好。

 1. 关键帧设置频率一般是多少？有没有根据接入动态设置？过长首屏秒会很难做到。
  关键帧间隔越长，也就是 GOP 越长，理论上画面越高清。但是生成 HLS 直播时，最小切割粒度也是一个 GOP，所以针对交互直播，通常不建议 GOP 设置太长。直播一般 2 个关键帧间隔即可。比如帧率是 24fps， 那么 2 个关键帧的间隔就是 48fps ，这个 GOP 就是2s。I 帧不是关键帧，IDR 帧才是。IDR 帧是 I 帧，但是 I 帧不一定是 IDR 帧。只有 IDR 帧才是可重入的。
 2.视频直播想在 HLS 流中无缝插入一段广告的 ts 文件，有问题想请教一下：1、这段 ts 的分辨率是否一定要和之前的视频流一致？2、pts 时间戳是否要和上一个 ts 递增？
  1、可以不一致。这种情况两段视频完全是独立状态，可以没有任何关系，只需要插入 discontinue 标记，播放器在识别到这个标记之后重置解码器参数就可以无缝播放，画面会很平滑的切换。2、不需要递增。举个例子，视频 A 正在直播，播放到 pts 在 5s 的时候，插入一个视频 B，需要先插入一个 discontinue，再插入 B，等 B 播放完之后，再插入一个 discontinue，再插入 A，这个时候 A 的 pts 可以和之前递增，也可以按照中间插入的 B 的时长做偏移，一般做点播和时移的时候 pts 会连续递增，直播的话会算上 B 的时长。

  很多常见的直播平台都采用了阿里云直播CDN来搭建自身业务。常见的CDN加速包括文件加速、点播、直播三种业务。
  其中内容分发网络就是大家常说的CDN，这里主要包含流媒体服务器，负载均衡，路由重定向，视频转码，视频录制存储，防盗链，性能等相关技术内容。

直播根据上行带宽的状况来调整码率、FPS、分辨率

所谓弱网优化的本质是一种策略。而弱网优化的效果取决于以下两点：
1）更精确和细粒度的检测网络的状况，便于推流端 SDK 调整参数。
2）更丰富的策略和更合理的选择。当 SDK 精确的反馈了网络的状况，我们需要做出正确的判断选择出一种合适的策略来应对。

> CDN分发及链路优化
-- CDN直播中常用的流媒体协议包括RTMP，HLS，HTTP FLV等。
 整个直播流程分为以下几个关键步骤：
 1、主播客户端，将本地采集的视频推送到CDN；
 2、CDN对视频流进行缓存以及转发；
 3、观众客户端，拉取CDN中缓存视频流进行播放；

-- CDN需要进行视频的合图，需要额外开发工作，并且逻辑比较复杂； CDN需要进行视频的合图，需要消耗较高服务器资源； CDN合图后的布局难控制； 所以对CDN要求奇高；

-- 基于SD-RTN的解决方案：
 客户端均通过UDP连接SD-RTN（Agora Global Network），通过SD-RTN的就近接入策略，让使用者就近接入质量最好的数据节点，通过Agora Global Network的软件定义优化路由，经过传输延迟和质量优化的最优路径，自动避免网络拥塞，并规避骨干网络故障的影响。

-- 采用SD-RTN做直播有如下特点：
1、可以支持更多的主播交互，目前支持7人视频交互，100人语音交互。
2、当有观众连麦时，其他观众端收到的多路视频，观众端可以动态选择布局；
3、声网Agora.io会将直播视频推送到CDN，其他观众（网页端等）可以直接观看；
4、当有观众连麦时，声网Agora.io会将视频合图后推送到CDN，其他观众（网页端等）可以观看到连麦者与主播的互动；
5、在经过RTMP推流前的观众端，可以进行大小流切换，自主选择视频大小窗口的切换。

> 直播性能指标：延迟、卡顿、首屏耗时
 第一个直播性能指标是延迟，延迟是数据从信息源发送到目的地所需的时间。
 第二个直播性能指标卡顿，是指视频播放过程中出现画面滞帧，让人们明显感觉到“卡”。
 第三个直播性能指标首屏耗时，指第一次点击播放后，肉眼看到画面所等待的时间。

  移动平台上视频直播的坑主要可以总结为两方面：设备差异，以及网络环境这些场景下带来的技术考验。即在推流端，可检测网络状态和简单测速，动态来切换码率，以保障网络切换时的推流流畅。其次编码、封包、推流 这一部分的逻辑也可以做微调，可以尝试选择性丢帧，比如优先丢视频参考帧（不丢 I 帧和音频帧 )，这样也可以减少要传输的数据内容，但同时又达到了不影响画质和版视听流畅的目的。
  音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
  图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。

-- 视频延迟和卡顿的原因和相应的优化原理。  视频直播技术延迟优化- https://www.jianshu.com/p/753bb974582f
 1)影响视频清晰度的指标：帧率；码率；分辨率；量化参数（压缩比）;
 2)影响视频流畅度的指标：码率；帧率;
 3)其他重要指标，直播是流量和性能的消耗大户：耗电量；发热（不好量化，大部分情况发热和耗电量正比，可以使用耗电量暂时替代）;

  直播卡顿：直播网络都不太稳定，有CDN节点不足的问题，也有主播端自身和代码的各种问题。直播应用卡顿直接原因：本地buffer为空导致播放停止。但从主播端->观看端整个流程看，网络状况、服务器性能都可能导致/加剧问题。
  直播首帧的优化：GOP缓存；CDN最近策略；UDP策略；local DNS
  视频里边的原始图像数据会采用 H.264 编码格式进行压缩，音频采样数据会采用 AAC 编码格式进行压缩。

-- 服务端优化，CDN 预缓存 GOP，以高倍速推送，缩短I帧等待时间：
  在直播服务器中，支持设置一个cache，用于存放GOP(就是I/P/B组起来的)，客户端播放。 
直播服务器缓存了当前的GOP序列，当播放端请求数据的时候，CDN会从I帧返回给客户端，从而保证客户端可以快速获取I 帧进行显示；当然，由于缓存的是之前的视频信息，当音频数据到达播放端后，为了音视频同步，播放器会进行视频的快进处理（也就是赶上，据说百度视频云，在~“赶上”~这块，还专门写了专利），但这种影响很小；相比于能够达到“秒开”的效果，这个代价是值得的；

-- 播放端优化：
  DNS解析加快，通常，DNS解析，意味着要把一个域名为xxx.com解析成ip过程，平时请求网页，网络差，就会打开网页半天。
修改播放器逻辑，基于FFmpeg二次开发，FFmpeg起播视频，都是拿到视频完整信息，才起播。能不不能只拿到部分信息，就起播。就要修改代码了。通常FFmpeg起播时，finder_decoder, avformat_find_stream_info较耗时，前者去找解码器，相对后者，又不那么耗时，凡事都有相对。

-- 视频优化：
   如果是仅仅优化首开延迟，可以在视频帧间插入较多的关键帧，这样客户端收到视频流之后可以尽快解码。但如果需要优化传输过程中的累计延迟，尽可能少使用关键帧也就是 I 帧（GOP 变大），在保证同等视频质量的情况下，I 帧越多，码率越大，传输所需的网络带宽越多，也就意味着累计延迟可能越大。这个优化效果可能在秒级延迟的系统中不是很明显，但是在 100 ms 甚至更低延迟的系统中就会非常明显。同时，尽量使用 ACC-LC Codec 来编码音频，HE-ACC 或者 HE-ACC 2 虽然编码效率高，但是编码所需时间更长，而产生更大体积的音频造成的传输延迟对于视频流的传输来说影响更小。

-- 相机图传。减少花屏，而造成的卡顿？
  花屏的原因是因为丢帧造成的，比如说丢失了 i帧，关键帧，后面的p帧送去给ffmpeg解码得到的图像是花屏，或者马赛克等等（也有一种是大p,小p的说法，这里就不详细说了），【注意，这个传输过程没有用到b帧，整个传输过程只有两种帧： i帧，一个p帧】,多一点花屏，可以减少卡顿，客户更能接受的是卡顿，而不是花屏。

> 直播秒开；直播中的I帧，P帧和 B帧，GOP等
  I 帧是内部编码帧（也称为关键帧），P 帧是前向预测帧（前向参考帧），B 帧是双向内插帧（双向参考帧）。简单地讲，I 帧是一个完整的画面，而 P 帧和 B 帧记录的是相对于 I 帧的变化。如果没有 I 帧，P 帧和 B 帧就无法解码。
  GOP ( Group of Pictures ) 是一组连续的画面，由一张 I 帧和数张 B / P 帧组成，是视频图像编码器和解码器存取的基本单位，它的排列顺序将会一直重复到影像结束。
  GOP 的第一帧通常都是关键帧，由于加载的数据较少，可以达到 “首帧秒开”。如果直播服务器支持 GOP 缓存，意味着播放器在和服务器建立连接后可立即拿到数据，从而省却跨地域和跨运营商的回源传输时间。
  GOP 体现了关键帧的周期，也就是两个关键帧之间的距离，即一个帧组的最大帧数。假设一个视频的恒定帧率是 24fps（即1秒24帧图像），关键帧周期为 2s，那么一个 GOP 就是 48 张图像。一般而言，每一秒视频至少需要使用一个关键帧。
 交互直播，通常不建议 GOP 设置太长。通常不建议 GOP 设置太长。直播一般 2 个关键帧间隔即可。比如帧率是 24fps， 那么 2 个关键帧的间隔就是 48fps ，这个 GOP 就是2s。

  直播首帧的优化：GOP缓存；CDN最近策略；UDP策略；local DNS；

  I帧可以seek，我们将它叫做关键帧。两个I帧之间叫做一个GOP。前向参考帧（P帧）和双向参考帧（B帧）。参考帧的意思就是根据I帧或者P帧进行参考，决定自己保留图片中的哪部分内容。参考帧越多，尤其是B帧越多，这个视频就越小，因为图片保留的部分就越少。 I帧是关键帧，一个完整画面，可以独立解码，P帧，是前向预测编码帧，可以理解为运动补偿帧，根据关键帧+运动补偿预测下一个关键帧。B帧，是双向预测编码帧，也是用来预测修补下一个I帧，所以B帧，P帧统称为参考帧。

  对于直播来讲，它是一个流，它不像点播，大家都从0秒开始，任何一个视频文件，0秒第一个帧肯定都是关键帧。那么对于直播来讲，我是一个随机的时间点接到这个视频流进行播放，那么我接入的这个时间点的帧有可能拿到的第一个帧的数据是I帧，也有可能是B帧，也有可能是P帧。这是一个随机的。在这种情况下，我们大概率会出现一个黑屏的状态。因为我拿到的是个P帧，对于P帧来讲，解码器面那个Buffer是空的，它不知道这个P帧如何进行解码，所以它只能丢弃这个帧。

-- 视频直播的GoP Size设置成多少合适：
   一般来讲，对于手机直播，一到两秒可能是比较合适的，因为它本身的GoP时间也不会很长，我这边缓冲，一旦出现问题大概一到两秒这个视频也能出来。有一个不太好的地方就是它码率会稍微高一些，也就说同样的东西，如果我把GoP改成十秒，我可能是500K，但是我改成一秒，有可能变成一个六七百K的样子，这个还是跟编码有关系，具体的比例是多少，可能跟实际相关。
   另外如果是点播的话，不关心首屏打开时间，只要是客户端下来速度快，CDN给力，那么我可能要求更小的范围。告诉大家一个实践过程中得出的结果，大家用过OBS?比如说做主播的话，大家用OBS会比较多，OBS它有一个问题就是它默认的话，如果你不调它的特性，GoP就是10秒，10秒的意思就是说GoP size。如果比较点背的话，看的是10秒之前的，如果是比较大的话，它的码率，码流的大小会小点，但是延迟会稍微高一些，CDN开了几个cache，有些情况下，我们也可以做些转码，强行把它的GoP size压小，整个CDN层面上加一个转码的话，它可能会增高这个延迟，这块一个开放性问题，大家可以根据自己的场景去思考，这个GoP Size配成多大比较合适。

 FFmpeg的数据结构里会标着PTS和DTS：PTS，Presentation Time Stamp也就说这个帧什么时候会放在显示器上;DTS就是Decode Time Stamp，就是说这个帧什么时候被放在编码器去解。那么如果全是I帧和P帧，PTS和DTS都是单调递增的。

-- 解码器相关的概念，码率（BitRate）、FPS（video frame per second）、分辨率（VideoSize），不断调整和调优、优化：
  在追求更好的流畅度时，我们可以适当降低码率。如果 FPS 已经较高（如 30）时，可以维持 FPS 不变更；如果此时因码率太低而画面无法接受，可以再适当调低 FPS。在追求更清晰的画质时，可以提高码率，FPS 调节至 24 左右人眼大多还会识别为流畅。如果可以接受有轻微卡顿，那么可以将 FPS 设置的更低，比如 20 甚至 15。
  动态调整编码策略是一种应对方式，而直接提高视频流的压缩比降低直播对网络的要求也是一种策略。目前如果使用 H.265 编码就可以降低 40% 的带宽占用，但比如 H.265 编码对移动端来说性能开销过大，相继会带来的问题还有发热过高、掉电过快等问题。

-- QQ空间直播秒开优化实践- http://www.androidchina.net/5198.html
直播速度优化一般有以下几个方向来解决问题：
  1、预加载。 2、缓存。3、串行变为并行，减少串行耗时。4、对单步骤中的耗时逻辑梳理优化。
根据这些方向，我们做的工作：
  1、预加载进程。  
  2、视频 SDK 上下文全局单例，并且预先初始化。
  3、并行预拉取接口机 IP，房间信息，预进入 av sdk 房间。
  4、接口机缓存首帧数据，减少 GOP 分片时间，修改播放器逻辑，解析到I帧就开始播放。

-- 百度LSS 音视频直播 秒开- http://blog.csdn.net/lcalqf/article/details/53048562https://cloud.baidu.com/doc/LSS/ProductDescription/30.5C.34.6A.7F.DD.32.EB.FE.F1.3F.24.C0.A2.2F.2C.13.0A.html

-- 首帧秒开+智能鉴黄+直播答题，阿里云直播系统背后技术大起底- https://yq.aliyun.com/articles/394552?spm=a2c4e.11155472.0.0.45165065faynZ2#
  淘宝的解决方案 :
 1.收流服务器主动推送 GOP 至边缘节点，边缘节点缓存 GOP，播放端则可以快速加载，减少回源延迟；
 2.根据TCP拥塞窗口做智能调度，当拥塞窗口过小说明丢包率过高，需要切换节点和故障排查；
 3.增加上行、下行带宽探测接口，当带宽不满足时降低视频质量，即降低码率 
通过这些优化手段，能够做到95%的直播点击后在900ms以内能够播放。

-- 移动端实时视频直播技术实践：如何做到实时秒开、流畅不卡- http://www.52im.net/thread-530-1-1.html
  直播技术，完整的处理环节包括但不限于：音视频采集、美颜/滤镜/特效处理、编码、封包、推流、转码、分发、解码/渲染/播放等。大部分播放器都是拿到一个完成的 GOP 后才能解码播放，基于 FFmpeg 移植的播放器甚至需要等待音画时间戳同步后才能播放（如果一个直播里边没有音频只有视频相当于要等待音频超时后才能播放画面）。

-- 视频直播秒开背后的技术与优化经验- https://blog.csdn.net/wishfly/article/details/53079303
  在视频直播中，首屏打开速度直接关系到用户体验，其中Group of Picture(GoP)设置、缓存参数优化格外关键。
  出现黑屏的原因很简单，就是解码器没有得到能解码出视频图像的数据，那么导致这个问题的原因就很容易定位了：比较搞笑一点的说法就是你家的网络比较慢;视频直播服务器没有打开关键帧缓冲。确实是这样。瞬间得到的数据正好是个I帧。就可以达到秒开的效果。
  对于H.264来讲，我们常见的有I帧，P帧，和B帧。IDR帧是I帧，但I帧并不一定是IDR帧。直播延迟 好的编解码策略。
视频解码器缓冲区开始的第一个帧肯定是I帧，这个毋庸置疑。

-- 移动直播技术秒开优化经验- http://blog.csdn.net/blade2001/article/details/51477550
 Android全平台兼容的成本不低：硬编/软编。移动直播技术其完整的处理环节包括但不限于：音视频采集、美颜/滤镜/特效处理、编码、封包、推流、转码、分发、解码/渲染/播放等。

ijkplayer 解决rtmp 延迟长的问题，达到秒开的结果- https://blog.csdn.net/yyhjifeng/article/details/71191950

> ijkplayer，弱网优化下的视频优化
弱网下移动端网络连接处理策略- http://mobile.51cto.com/hot-557695.htm#topx
   如何度量和模拟“弱网络”对移动APP的开发有着重大的意义，比如：节约测试成本、易于问题重现、加快产品上线等。一般的方法是使用“丢包率”和“网络延时”来定义和衡量“弱网络”。

-- 直播技术总结（三）ijkplayer的一些问题优化记录- http://blog.csdn.net/hejjunlin/article/details/57075026 
 差网络环境下对视音频数据一般有四种处理方式：缓存区设计、网络检测、丢帧处理、降码率处理。
 视频经过编码后有关键帧和非关键帧：关键帧也就是一副完整的图片，而非关键帧描述图像的相对变化。 
 丢帧策略多钟多样，可以自行定义，一个需要注意的地方是：如果要丢弃P帧（非关键帧），那么需要丢弃两个关键帧之间的所有非关键帧，不然的话会出现马赛克。对于丢帧策略的设计因需求而异，可以自行进行设计。
  //ijkplayer 播放rtmp等 实时性，把其缓存设置变小（直播）
ijkMediaPlayer.setOption(IjkMediaPlayer.OPT_CATEGORY_CODEC, "skip_loop_filter", 8);
ijkMediaPlayer.setOption(1, "analyzemaxduration", 100L);
ijkMediaPlayer.setOption(1, "probesize", 10240L);
ijkMediaPlayer.setOption(1, "flush_packets", 1L);
ijkMediaPlayer.setOption(4, "packet-buffering", 0L);
Ijkplayer.setOption(IjkMediaPlayer.OPT_CATEGORY_PLAYER, "framedrop", 5);// Ijkplayer音视频不同步问题设置

  抖动缓冲区用于解决直播时网络抖动的问题。所谓网络抖动，就是网络延迟一会大一会小。抖动缓冲区 JitterBuffer，JitterBuffer的缓冲深度取决于网络抖动的程度，网络抖动越大，缓冲深度越大，播放音频的延迟就越大。所以，JitterBuffer是利用了较高的延迟来换取声音的流畅播放的，因为相比声音一卡一卡来说，稍大一点的延迟但更流畅的效果，其主观体验要更好。

-- 所谓弱网优化的本质是一种策略。而弱网优化的效果取决于以下两点：
 1）更精确和细粒度的检测网络的状况，便于推流端 SDK 调整参数。
 2）更丰富的策略和更合理的选择。当 SDK 精确的反馈了网络的状况，我们需要做出正确的判断选择出一种合适的策略来应对。

  直播想延伸到户外需要克服很多困难，而最主要的困难就是应对不稳定的网络。移动网络下，通常容易遇到网络不稳定，连接被重置，断线重连，一方面频繁重连，建立连接需要开销；另一方面尤其是发生 GPRS/2G/3G/4G 切换时，带宽可能出现瓶颈。当带宽不够，帧率较高/码率较高的内容较难发送出去，这个时候就需要我们在不同网络状况执行不同的策略编码推流，让观众可以看到最优质的直播视频。

-- 手机接入服务器的流程:
  首先，手机要通过无线网络协议，从基站获得无线链路分配，才能跟网络进行通讯。
无线网络基站、基站控制器这方面，会给手机进行信号的分配，已完成手机连接和交互。
  获得无线链路后，会进行网络附着、加密、鉴权，核心网络会检查你是不是可以连接在这个网络上，是否开通套餐，是不是漫游等。核心网络有SGSN和GGSN，在这一步完成无线网络协议和有线以太网的协议转换。
  再下一步，核心网络会给你进行APN选择、IP分配、启动计费。
 再往下面，才是传统网络的步骤：DNS查询、响应，建立TCP链接，HTTP GET，RTTP RESPONSE 200 OK，HTTP RESPONSE DATA，LAST HTTP RESPONSE DATA，开始UI展现。

-- 总结的一秒钟法则：在一秒内要完成的规定动作：
 2g网络：1秒内完成dns查询、和后台服务器建立连接；
 3g网络：1秒内完成首字显示(首字时间)；
 wifi网络：1秒内完成首屏显示(首屏时间)；
 这些指标需要在终端度量，必须跟用户体验相关：首字时间、首屏时间都必须是用户可以直观感受到的。

> 直播协议，如何优化传输机制来实现实时音视频的超低延迟- https://juejin.im/entry/59a7c84bf265da24777a0836
  音频社交 SDK、视频社交 SDK 或者游戏语音 SDK。如果是视频直播 SDK，一般会选择 RTMP 协议，因为要能够普遍兼容 CDN 分发网络，从而向围观的广大用户进行直播。如果是音频社交 SDK、视频社交 SDK 或者游戏语音 SDK，一般会选择 RTP/RTCP 协议（或者类 RTP 的私有协议），因为不需要通过 CDN 网络向围观用户广播媒体流。是否要考虑兼容 CDN 网络，是语音视频通话 SDK 和视频直播 SDK 的重大区别。
  RTMP 协议是基于 TCP 协议的，RTP 协议或者私有协议是基于 UDP 协议的，因此 RTMP 协议和 RTP 协议之争，本质就是 TCP 协议和 UDP 协议之争。

-- app端视频播放的解决方法的两个选择，一个是tcp传输，一个是udp传输。根据实测，tcp效果更好一点。 
 1.tcp ：数据传输过程，能保正数据的完整，所以花屏少点，距离相对upd会近一点， 
 2.udp：传输过程不保证数据的完整性，容易花屏，距离比较远。
  app端接收不及时，造成数据丢失而引起的卡顿。

  实时语音视频通话要获得超低延迟，不能仅仅依靠在各个环节不断地优化，而是要通过 FEC、ARQ 和码率自适应构建实时通讯机制。在这个基础上，还要充分考虑网络情况、实时要求和成本因素，以及需要大量经验数据的支撑（比如说，PLR 和 RTT 的关键阈值等）。要比较妥善的做到上面的要求，对语音视频技术团队绝对是一个严峻的考验。
  整个直播流转的过程是：推流端将视频流推向源服务器，源服务器对视频流进行编码或者转存，CDN负责负载均衡与缓存，CDN节点从源服务器获取视频流，播放端再从CDN上把视频流拉下来。

  HLS：HLS本身请求的是一个m3u8格式的文件。直播流会首先下载当前生成好的m3u8文件，再去一个一个下载里面的分片视频，所以对于源服务器来讲，生成好了一个m3u8文件之后，客户端才可能会拉到这个视频流，这也造成了HLS协议高延迟的问题。倘若一个m3u8文件里面所有的分片长度为10s，那么客户端拉到这个视频流的延迟至少为10s。
  rtmp：rtmp全称Real Time Messaging Protocol，是一种基于TCP的数据通信协议，广泛的被应用于流媒体的传输中来，此协议是实时传输数据流，所以延迟比HLS要低，由于具备TCP协议的拥塞控制，对数据的完整性有一定保证。与此同时，Adoube对rtmp协议的支持也做的很好，Flash可以完美的支持rtmp协议的视频流播放，大多数推流端都使用rtmp协议进行推流。
  http-flv：http-flv是通过http协议传输flv的视频流，HTTP协议中有个content-length字段，规定了请求http的body部分的长度，如果请求的时候不加content-length字段，那么客户端会一直收到数据。基于传输包的http-flv协议可以将数据包做的比rtmp做的更小，在流量上有比较大的优势，而延迟几乎和rtmp相同。