PLCameraStreamingKit

移动端因网络环境不稳定及用户电量宝贵等原因，并不建议直接使用最高码率和分辨率来做推流，以最佳编码参数来做设置可以带来更好的推流效果和用户体验。

buffer 是一个可以缓存待发送内容的队列，它按照帧数作为缓存长度的判定，可以通过 maxCount 来读取和设定，buffer 的阈值设定体现你期望的变更推流质量的策略，默认阈值为 buffer 的 50%(0.5)。

PLCameraStreamingKit
H.264 硬编码
AAC 硬编码
RTMP 推流
GPUImage 滤镜接入
SDK 是否包含采集
是否内置水印
是否可定制美颜

videoProfileLevel
H.264 编码时对应的 profile level 影响编码压缩算法的复杂度和编码耗能。设置的越高压缩率越高，算法复杂度越高，相应的可能带来发热量更大的情况
videoSize
编码的分辨率，对于采集到的图像，编码前会按照这个分辨率来做拉伸裁剪
videoFrameRate
即 FPS，每一秒所包含的视频帧数
videoMaxKeyframeInterval
两个关键帧的帧间隔，一般设置为 FPS 的三倍
videoBitRate
平均的编码码率，设定后编码时的码率并不会是恒定不变，静物较低，动态物体会相应升高。
PLStreamingKit

视频对应的参数为
分辨率 (320, 480)(720, 480)
视频最大关键帧间隔fps: 30
视频编码码率 Video BitRate(Kbps) ：1200Kbps （1200 * 1000）

音频取样频率Audio Samplerate(MHz)): 44MHz

音频码率Audio BitRate(Kbps)：96

因为直播推流实时性很强烈，所以为了保证这一实时性，在网络带宽不足或者上行速度不佳的情况下，都需要做出选择。
要么选择更好的流程度但牺牲清晰度（模糊），要么选择更好的清晰度但牺牲流畅度（卡顿），这一层的选择大多由产品决定

7.2 DNS 优化

在大陆一些地区或特别的运营商线路，存在较为普遍的 DNS 劫持问题，而这对与依赖 DNS 解析 rtmp 流地址的 PLStreamingKit 来说是很糟糕的情况，为了解决这一问题，我们引入了 HappyDNS 这个库，以便可以实现 httpDNS，localDNS 等方式解决这类问题。

7.2.1 HappyDNS

你可以 点击这里 跳转到 HappyDNS 的 GitHub 主页，在那里查看更详细的介绍和使用。

默认情况下，你所创建的 PLStreamingSession 对象，内部持有一个 HappyDNS 对应的 manager 对象，来负责处理 DNS 解析。

如果你期望按照不同的规则来做 DNS 解析，那么你可以在创建 PLStreamingSession 前，创建好自己的 QNDnsManager 对象，我们在 PLStreamingSession 中提供了一个 init 方法满足这类需求，你可以传递自己的 QNDnsManager 对象给 PLStreamingSession，从而定制化 DNS 解析。

7.3.1 丢帧策略的必要性

我想可能没有人会喜欢在直播中出现丢帧，但是为何我们一定要实现并提供它呢？这是我们在最初提供出丢帧策略时也在反复考虑和一再讨论过的一个问题。

原因很简单，为了保证直播的实时性。

直播作为有别于录播的富媒体传播手段，它的第一要素就是实时，没有了实时，直播的价值就会荡然无存。保证实时性就需要确保录制端的数据尽可能少的累积，尽可能快的发送，但如果没有丢帧策略，在弱网环境下，就会因为待发送数据的不断堆积而产生累计延时，最终带来延时越来越大的情况。作为推流的发起端和推送端，推流 SDK 要考虑的还不单单是实时性这一点，因为移动设备的内存有限，而视频数据对内存的占用较大，所以在推流时还要确保不会因为待发送数据堆积过多而带来内存吃紧，触发 crash 等严重问题。所以我们需要也一定要在推流端提供丢帧策略。

丢帧的方式可以有很多种，其中有些较为粗暴，会触发各类问题，比如花屏，爆音，音画不同步等问题，在反复尝试和验证了各类的丢帧策略后，我们最终选定了优先保证音频传输且不触发花屏、爆音、音画不同步问题的技术方案。这一方案可以保证在带宽不足或上行速度不佳时，优先丢弃视频帧，保证音频的持续传输，在观看端至多出现画面跳帧的情况，但声音会是连续的片段，体验上不会认为是推流端断网，确保直播的继续进行。

7.3.2 利弊

丢帧策略固然保证了直播的实时性和推流端相对的稳定性，但是它的弊端也是显然的，就是会带来观看端体验的不佳。

面对并接受这一弊端是必要，这样才可以做出更好的产品决策，我们建议从产品层面至少需要考虑两点

在主播弱网情况下，观看端体验要保证流畅度优先还是清晰度优先
在主播弱网情况下，尽可能让主播自己知晓自己网络不佳这一事实
对于流畅度和清晰度的问题，可以参见 7.1.1.3 码率、fps、分辨对清晰度及流畅度的影响 这一小节。重点内容

7.4.3 status 状态回调

除了 state 作为流本身状态的切换，我们还提供了流实时情况的反馈接口

• (void)streamingSession:(PLStreamingSession )session streamStatusDidUpdate:(PLStreamStatus )status;
  默认情况下，该回调每隔 3s 调用一次，每次包含了这 3s 内音视频的 fps 和总共的码率（注意单位是 kbps）。你可以通过 PLStreamingSession 的 statusUpdateInterval 属性来读取或更改这个回调的间隔。

7.4.4 产品层面的反馈

status 的状态回调可以很好的反应发送情况，及网络是否流畅，是否拥塞。所以此处可以作为产品层面对弱网情况决策的一个入口。

一般的，当 status.videoFPS 比预设的 FPS 明显小时（小于等于 20%），并且维持几秒都是如此，那么就可以判定为当前主播所在的网络为弱网环境，可以给主播视觉上的提示，或者主动帮她降低编码配置，甚至直接断掉主播的流，这些都由具体的产品需求而定，而此处只是给出一个入口的提示和建议。