音视频直播总结

采集 -> 处理 -> 编码 -> 封装 -> 推流 -> 分发
采集: 视频 YUV
音频:PCM
处理:
磨皮,美白,会涉及到人脸识别技术和皮肤识别技术;
编码:
压缩编码,根据前后帧的特点可以实现压缩;
连续几个帧放在一起就形成了组GOP,将该组分为I/B/P,I表示为关键帧,B表示为双向参考帧,P表示为向前参考帧,如果没有I帧,B,P帧也是没法播放的,因为B,P帧是根据I帧计算得来的。

压缩主要包含以下几个方向:

空间冗余:

空间冗余表示为一个头像间的冗余,会在一个头像空间内压缩;

时间冗余:

因为前后帧的关系,出现的冗余;

视觉冗余:
视觉冗余是排除人眼不敏感的部分,以达到压缩的目的;

编码冗余:

编码冗余也叫信息熵冗余,是因为不同的编码所占的二进制位是不同的,同步优化编码来节省空间;

编码:

H.264 H.265
优点 编码快,支持最好 省空间,重码率低
缺点 没有H265省空间 兼容性不如H264
acc mp3
优点 音质好,存储小,使用越来越广泛 使用广泛
缺点 - 会有一定的失真

综上:采用H.254 + acc的方案是比较合适的;

封装:
封装就是对编码后的内容进行打包;另外可以打上时间戳,避免音画不同步;

推流:

两种推流形式:
tcp:rtmp,rtmp是adobe的私有协议,已经不再维护,推流需封装成flv;

udp:webRTC,视频会议用的比较多,google出品;

rtmp webRTC
优点 cdn都支持,用的最多,实现简单 开源的,基于udp意味着直播的时候相对弱网可能会有一些丢包策略;
缺点 基于tcp协议,有超时重传机制,意味着在弱网下,稳定性可能会出问题 cdn支持不良

接收:
流媒体协议用的最多的三个: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;