采集 -> 处理 -> 编码 -> 封装 -> 推流 -> 分发
采集： 视频 YUV
音频：PCM
处理：
磨皮，美白，会涉及到人脸识别技术和皮肤识别技术；
编码：
压缩编码，根据前后帧的特点可以实现压缩；
连续几个帧放在一起就形成了组GOP,将该组分为I/B/P,I表示为关键帧，B表示为双向参考帧，P表示为向前参考帧，如果没有I帧，B,P帧也是没法播放的，因为B,P帧是根据I帧计算得来的。
压缩主要包含以下几个方向：
空间冗余：
空间冗余表示为一个头像间的冗余，会在一个头像空间内压缩；
时间冗余：
因为前后帧的关系，出现的冗余；
视觉冗余：
视觉冗余是排除人眼不敏感的部分，以达到压缩的目的；
编码冗余：
编码冗余也叫信息熵冗余，是因为不同的编码所占的二进制位是不同的，同步优化编码来节省空间；
编码：
综上：采用H.254 + acc的方案是比较合适的；
封装：
封装就是对编码后的内容进行打包；另外可以打上时间戳，避免音画不同步；
推流：
两种推流形式：
tcp:rtmp，rtmp是adobe的私有协议，已经不再维护，推流需封装成flv;
udp：webRTC，视频会议用的比较多，google出品；
接收：
流媒体协议用的最多的三个：rtmp,http-flv,hls;
其中rtmp,http-flv都是flv格式的，延迟在2-4s,实时性差不多，其中rtmp是存储在服务端的，http-flv是存储在客户端的，都不支持web播放；
hls:
唯一一个支持h5播放的流媒体协议，延迟4~10s,格式是ts+m3u8,观看的时候先把一组.ts视频下载，然后通过m3u8的索引去观看，因为要先下载（N个ts文件+一个m3u8文件），所以延迟和段数有光，实时性不会太好；
ts标准较复杂；
点播与直播：
点播： 点播使用的都是http协议，直播主要用的是RTMP，HTTP-FLV，HLS等；
FFmpeg:
FFmpeg主要用于解码播放；
直播服务器：
RED5、CRTMPD、NGINX-RTMP和SRS;