直播市场的火爆，带动整个产业链上各个环节的蓬勃发展，进来自身的产品遇到的一些技术性的问题，让我好奇并注意了流媒体直播服务这块大肥肉。
因为直播这类产品自身的属性，决定了实现过程中有不少技术性很强（如音视频的编解码、终端的推流拉流功能）、抑或实现成本相当高（如音视频的分发CDN服务、编解码服务）的技术模块，这些环节上往往性能好坏的重要性大过功能的实现。
在研究这些第三方服务商之前，先了解下一个完整的移动直播系统是什么样的：
1、推流端（采集、前处理、编码、推流）
采集：通过摄像头、麦克风采集视频、音频数据。视频数据一般采用RGB或YUV格式，音频一般采用PCM格式
前处理：美颜、水印、模糊等。GPUImage提供120多种滤镜效果，支持IOS和android
编码：为便于推流、拉流和存储，通过视频编码来减小视频体积。H264/H265为常见视频编码，AAC/mp3/wma是常见音频编码。通俗说：编码器将多张图片编码后产生一段GOP(group of pictures)，解码时播放器读取一段GOP进行渲染显示。编码的核心是在分辨率、码率、帧率等参数中找到平衡点，得到体积最小画面最优的效果。硬件编码是手机直播的首选，但ios上兼容效果好，android上全平台兼容比较难。
关于码率、分辨率与清晰度、帧率和流畅度如何理解？
码率和分辨率都和清晰度有关，分辨率指对一副画面的分割粒度，码率指编码时对分割后的这幅画面的采样频率。可以说码率是决定下限 分辨率决定上限，分辨率再高 码率不够 都不清晰，码率高 分辨率不高也不清晰；帧率是视频被截成画面的采样率，帧率高流畅度高，和画面清晰度无关。
推流：把音视频协议使用传输协议封装会变成流数据。常见流传输协议rtsp/rtmp/hls，rtmp在手机直播中最常见。流数据推到CDN上进行分发。这个过程需要解决网络不稳定的问题，优化一方面在于CDN的优化，一方面是两端的策略优化，例如两端设置缓存，让码率均匀；动态的码率和帧率以适应实时变化的网络状态。
2、服务端处理（转码、录制、截图、抄送审核）
转码：为适配终端和平台，需要对流进行转码，如支持rtmp/hls/flv格式的拉流，支持一路转多路，适配不同网络和分辨率的终端设备。自己搭建转码系统成本很高。
截图、录制和水印：为了审核、直播视频的再消费等需要，直播流需要进行截图
审核：机器对色情画面的监控；人工审核的操作系统
3、播放器（拉流、解码、渲染）
拉流：拉流是推流的逆过程。标准拉流格式有rtmp/hls/flv。rtmp是adobe的专利协议，直播延迟一般在1~3s；hls是苹果提出的基于http的流媒体协议，html5可以直接打开播放，缺点是延时通常大于10s；flv直播延时也能达到1~3s。
解码和渲染：解码是编码的逆过程。为了支持高清，需要选择硬解码。渲染最大的难点不在于画面的绘制，而是音视频的同步。
4、互动系统（聊天室、礼物系统、赞）
这里涉及到的消息的实时性和互动性，大多是用IM的功能来实现的，对服务器的压力也很大。产品策略上会辅助做一些优化，减轻服务器压力，例如限制发消息的频率，每条消息发送对象的上限限制。
礼物系统：实际上也是通过IM消息来实现的，礼物是一种自定义消息，收到消息时可以通过图形渲染出来。面对大量用户刷礼物时，对于礼物的一致性要求很高，一般技术上采用一份数据存多条索引，可以减低对事务的依赖。
