Android IOS WebRTC 音视频开发总结（七十）-- 移动端音视频技术优化的七个方向

最近直播很火，很多朋友对背后的技术比较感兴趣，所以今天我们整理一篇关于移动端视频优化的文章，这篇文章是我朋友在一个技术大会上分享过的，更多内容请关注我们的微信公众号：rtcblacker

 

视频直播为什么会这么火？

首先，音视频直播、点播的需求一直大量存在，包括各种行业应用，比如视频门户、娱乐直播、游戏直播、在线教育、远程医疗，远程监控，企业协作，社交应用等等。“以前之所以没有全面爆发，是因为硬件条件不满足，比如网络的带宽有限”，目前网速仍在不断提升，光纤普及到小区，有线网络的上下行带宽已经达到要求，“移动网络4G接入速度也很快，满足了基本的视频直播带宽要求。而且网络资费也比较低，变得大众可接受。”

 

其次，智能硬件设备大量普及，特别是大屏智能手机、平板，基本是人手一台。同时这些设备的性能也越来越强劲。硬件性能的提升解决了视频编解码的性能瓶颈，可以拿手机、平板作为PC机器使用。

 

再次，回到商业本质就是直播赚钱快，有兴趣的朋友可以看看我之前写的：三个角度分析美女视频直播这个行业

 

接下来看看移动端音视频技术优化的几个方向：

第一，选择通用性好，性能良好，复杂度相对较低的编码器，主流的是H.264编码器，开源的主要是x264和openh264，其中openh264是思科开源项目，针对实时视频通话场景做了优化。另外vp8也针对移动端也做了很多优化。

 

第二，在选定一个编码标准之后，就要看是否采用硬件编码方式，如果采用软件编码，那么会比较耗费cpu资源，表现出来就是设备发烫，耗电快，但是设备兼容性好，几乎可以在任何设备上运行。如果采用硬件编码方式，那么编码性能好，完全可以支持1080p图像全高清的实时编码，而且也省电，但是设备的适配性比较差，特别Android设备的硬件编码模式支持的比较差。ios设备支持的适配性比较好，但是，没有开放更底层的编码接口，难做到按帧获取码流，进行实时直播。另外用硬件编码方式，也比较难做动态码率控制。针对网络直播和点播场景，在编码阶段要尽量做到码率波动的平滑，这个需要优化码率控制算法。

第三，对于Gop的大小也要根据应用场景做适当的调整，如果关键帧之间的间隔小，那么码率会出现频繁的尖峰，发送数据的时候，会造成瞬间的拥塞。
　　

第四，可以通过设置buffer来解决码率波动问题，比如在推流端增加一个发送缓冲区，按照固定的码率发送数据，而不是根据每帧数据来发送。同样在播放器也可以设置一个接收buffer，解决网络波动对播放造成的频繁卡顿。但是这个设置过大的buffer会增加延时，不适合直播应用，比较适合点播应用。对于直播场景，要求端到端的延时尽量小，播放端能快速启动，看到画面。对于rtmp直播还要解决累计延时，可以采用在播放器主动清空buffer的方法。
　　

第五，不管是直播还是点播服务，都存在一个端到端的数据传输链路问题。在推流端先要连接到接流服务器，这时就要选择合适的节点，一种是根据客户端的DNS域名来选择就近的节点，当DNS配置有误的时候，可能会存在调度不准的问题。另外一种是根据客户端的出口IP来选择节点，这种调度方式会比较准确一些。同样对于播放器端也是采用类似的方式来选择流媒体服务器集群的边缘节点。
　　

第六，在整个直播或点播过程中，最好有实时统计数据，包括网络类型，机器信息，实时网络状况，帧率，码率，分别率等。这样可以分析遇到的各种问题，特别是对于直播场景，当网络波动，出现卡顿时，可以为动态调整qos提供依据。
　　

第七，对于直播场景，采用qos策略，动态调整编码参数，包括帧率，码率，分辨率，缓冲区。当直播出现卡顿，采用快降慢升的策略，当网络波动比较厉害，这样可以避免编码参数频繁的来回调整，造成恶性循环。当进行编码参数调整时，一般是根据分辨率把码率，帧率分成几个档次，然后在根据一定时间段内的统计数据，在这几组参加集会之间进行来回切换，确保音视频流畅的同时，尽量提高图像质量。

 

喜欢系列文章，欢迎扫描下方二维码关注我们的公众号：rtcblacker