Skip to content

6 知识补充与建议

Jump to bottom Edit New page
hugo.lee edited this page Mar 30, 2017 · 3 revisions

6 知识补充与建议

6.1 编码相关参数说明

6.1.1 码率、fps、分辨率对清晰度及流畅度的影响

对于码率（BitRate）、FPS（video frame per second）、分辨率（VideoSize）三者的关系，有必要在这里做一些说明，以便你根据自己产品的需要可以有的放矢的调节各个参数。

一个视频流个人的感受一般来说会有卡顿、模糊等消极的情况，虽然我们都不愿意接受消极情况的出现，但是在 UGC 甚至 PGC 的直播场景中，都不可避免的要面对。因为直播推流实时性很强烈，所以为了保证这一实时性，在网络带宽不足或者上行速度不佳的情况下，都需要做出选择。

要么选择更好的流程度但牺牲清晰度（模糊），要么选择更好的清晰度但牺牲流畅度（卡顿），这一层的选择大多由产品决定。

一般来说，当选定了一个分辨率后，推流过程中就不会对分辨率做变更，但可以对码率和 FPS 做出调节，从而达到上述两种情况的选择。

效果 码率 FPS
流畅度 负相关 正相关
清晰度 正相关 负相关

通过这个关联，我们就可以容易的知道该如何从技术层面做出调整。在追求更好的流畅度时，我们可以适当降低码率，如果 FPS 已经较高（如 30）时，可以维持 FPS 不变更，如果此时因为码率太低而画面无法接受，可以再适当调低 FPS；在追求更清晰的画质时，可以提高码率，FPS 调节至 24 左右人眼大多还会识别为流畅，如果可以接受有轻微卡顿，那么可以将 FPS 设置的更低，比如 20 甚至 15。

总之，这三者之间一起构建其了画面清晰和视频流畅的感觉，但最终参数是否能满意需要自己不断调整和调优，从而满足产品层面的需求。

6.1.2 建议编码参数

提示：以下为建议值，可根据产品需求自行更改调节。

UGC 场景，因为主播方所在的网络环境参差不齐，所以不易将码率设置的过高，此处我们给出建议设定：

  • WiFi: VIDEO_QUALITY_MEDIUM2 或者自定义编码参数时设定码率为 800Kbps
  • 3G/4G: VIDEO_QUALITY_MEDIUM1 或者自定义编码参数时设定码率为 512Kbps

PGC 场景，因为主播方所在网络一般都会有较高的要求，并且主播网络质量大多可以保障带宽充足，此处我们给出建议设定：

  • WiFi: VIDEO_QUALITY_HIGH1 或者自定义编码参数时设定码率为 1200Kbps
  • 3G/4G: VIDEO_QUALITY_MEDIUM2 或者自定义编码参数时设定码率为 800Kbps

对于 PGC 中的 3G/4G 场景，假定 PGC 时会配备较好的外置热点保证上行带宽充足。

6.2 网络异常处理

6.2.1 重连

在网络断开、sendTimeOut 后没有发出数据、网络链接被服务端断开等网络异常后，SDK 会：

  • STATE.DISCONNECTED 消息会被回调；
  • 当 SDK 内部处理完一些必要的清理工作后，如果实现了 StreamingSessionListener interface 并调用了对应的注册函数 mCameraStreamingManager.setStreamingSessionListener(this);， StreamingSessionListener.onRestartStreamingHandled 将会被回调，用户可以在这里进行重连，即 mCameraStreamingManager.startStreaming();
  • 若网络不可达（即网络断开等情况），尝试重连之后，会返回 STATE.IOERROR，可以不用担心循环重连的问题。

需要注意的是，在网络层会有三次重连的机会，即没有必要在收到 STATE.IOERROR 之后继续进行重连，一般接收到 STATE.IOERROR 代表无法通过网络和服务端建立链接。

重连可以很好地避免网络抖动导致的断流，建议正确实现重连逻辑，可以提升用户体验。

6.3 丢帧策略

这一章节，我们谈谈追帧策略，这关乎最终的直播观看体验，这里我们主要说明为何需要它，以及它带来的利弊。

6.3.1 丢帧策略的必要性

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

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

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

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

6.3.2 利弊

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

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

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

Add a custom footer
Clone this wiki locally