|
|
|
|
|
# 视频直播iOS端技术
|
|
|
|
|
|
|
|
|
|
|
|
直播架构
|
|
|
|
|
|
|
|
|
|
|
|
想必了解过直播的人都清楚直播主要分为3部分:推流->流媒体服务器->拉流。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
而我们今天需要讲的就是推流这部分，它主要包括音视频采集，音视频前处理，音视频编码，推流和传输4个方面。但是由于网络的复杂性和大数据的统计，推流还需要有全局负载均衡调度GSLB（Global Server Load Balance）,以及实时的统计数据上报服务器，包括提供频道管理给用户运营，因此推流SDK需要接入GSLB中心调度，统计服务器，心跳服务器，用于推流分配到网络最好的节点，有大数据的统计和分析。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
下图涵盖了直播相关的所有服务，红色小标的线条代表指令流向，绿色小标的线条代表数据流向。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
●●●
|
|
|
|
|
|
|
|
|
|
|
|
直播技术点
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
音视频采集
|
|
|
|
|
|
|
|
|
|
|
|
采集是所有环节中的第一环，网易云通信与视频使用的系统原生框架AVFoundation采集数据。通过iPhone摄像头(AVCaptureSession)采集视频数据，通过麦克风(AudioUnit)采集音频数据。目前视频的采集源主要来自摄像头采集、屏幕录制（ReplayKit）、从视频文件读取推流。
|
|
|
|
|
|
|
|
|
|
|
|
音视频都支持参数配置。音频可以设置采样率、声道数、帧大小、音频码率、是否使用外部采集、是否使用外部音频前处理；视频可以设置帧率、码率、分辨率、前后摄像头、摄像头采集方向、视频端显示比例、是否开启摄像头闪光灯、是否打开摄像头响应变焦、是否镜像前置摄像头预览、是否镜像前置摄像头编码、是否打开滤镜功能、滤镜类型、是否打开水印支持、是否打开QoS功能、是否输出RGB数据、是否使用外部视频采集。
|
|
|
|
|
|
|
|
|
|
|
|
音视频处理
|
|
|
|
|
|
|
|
|
|
|
|
前处理模块也是主观影响主播观看效果最主要的环节。目前iOS端比较知名的是GPUImage，提供了丰富的预处理效果，我们也在此基础上进行了封装开发。视频前处理包含滤镜、美颜、水印、涂鸦等功能，同时在人脸识别和特效方面接入了第三方厂商FaceU。SDK内置4款滤镜黑白、自然、粉嫩、怀旧；支持16:9裁剪；支持磨皮和美白（高斯模糊加边缘检测）；支持静态水印，动态水印，涂鸦等功能。音频前处理则包括回声抑制、啸叫、增益控制等。音视频都支持外部前处理。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
音视频编码
|
|
|
|
|
|
|
|
|
|
|
|
编码最主要的两个难点是:
|
|
|
|
|
|
|
|
|
|
|
|
处理硬件兼容性问题
|
|
|
|
|
|
|
|
|
|
|
|
在高FPS、低bitrate和音质画质之间找个一个平衡点
|
|
|
|
|
|
|
|
|
|
|
|
由于iOS端硬件兼容性比较好，因此可以采用硬编。SDK目前支持软件编码openH264，硬件编码VideoToolbox。而音频支持软件编码FDK-AAC和硬件编码AudioToolbox。
|
|
|
|
|
|
|
|
|
|
|
|
视频编码的核心思想就是去除冗余信息:
|
|
|
|
|
|
|
|
|
|
|
|
空间冗余:图像相邻像素之间有较强的相关性。
|
|
|
|
|
|
|
|
|
|
|
|
时间冗余:视频序列的相邻图像之间内容相似。
|
|
|
|
|
|
|
|
|
|
|
|
编码冗余:不同像素值出现的概率不同。
|
|
|
|
|
|
|
|
|
|
|
|
视觉冗余:人的视觉系统对某些细节不敏感。
|
|
|
|
|
|
|
|
|
|
|
|
音视频发送
|
|
|
|
|
|
|
|
|
|
|
|
推流SDK使用的流媒体协议是RTMP（RealTime Messaging Protocol）。而音视频发送最困难的就是针对网络的带宽评估。由于从直播端到RTMP服务器的网络情况复杂，尤其是在3G和带宽较差的Wifi环境下，网络丢包、抖动和延迟经常发生，导致直播推流不畅。RTMP基于TCP进行传输，TCP自身实现了网络拥塞下的处理，内部的机制较为复杂，而且对开发者不可见，开发者无法根据TCP协议的信息判断当时的网络情况，导致发送码率大于实际网络带宽，造成比较严重的网络拥塞。因此我们自研开发了一款实时根据网络变化的QoS算法，用于实时调节码率、帧率、分辨率，同时将数据实时上报统计平台。
|
|
|
|
|
|
|
|
|
|
|
|
●●●
|
|
|
|
|
|
|
|
|
|
|
|
模块设计&线程模型
|
|
|
|
|
|
|
|
|
|
|
|
模块设计
|
|
|
|
|
|
|
|
|
|
|
|
鉴于推流的主流程分为上述描述的4个部分：音视频采集、音视频前处理、音视频编码、音视频发送。因此将推流SDK进行模块划分为LSMediacapture层（对外API+服务器交互）、视频融合模块（视频采集+视频前处理）、音频融合模块（音频采集+音频前处理）、基础服务模块、音视频编码模块、网络发送模块。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
线程模型
|
|
|
|
|
|
|
|
|
|
|
|
推流SDK总共含有10个线程。视频包含AVCaptureSession的原始采集线程、前处理线程、硬件编码线程、数据流向定义的采集线程、编码线程、发送线程。音频包含AudioUnit包含的原始采集线程、数据流向定义的采集线程、编码线程、发送线程。在数据流向定义的采集线程、编码线程、发送线程之间会创建2个bufferQueue，用于缓存音视频数据。采集编码队列可以有效的控制编码码率，编码发送队列可以有效自适应网络推流。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
QoS&跳帧
|
|
|
|
|
|
|
|
|
|
|
|
下图是直播的主要流程，用户初始化SDK，创建线程，开始直播，音视频数据采集，编码，发送。在发送线程下，音视频数据发送，QoS开启，根据网络实时评估带宽，调整帧率，码率控制编码器参数，同时触发跳帧，调整分辨率控制采集分辨率参数。用户停止直播，反初始化SDK，销毁线程。QoS&跳帧可以有效的解决用户在网络不好的情况下，直播卡顿的问题。在不同的码率和分辨率情况下，都能够做到让用户流畅地观看视频直播。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
原文https://zhuanlan.zhihu.com/p/31178008
|
