最近在负责做直播电商系统，需要对音视频推拉流进行学习。
1. 推拉流：
什么是推流
推流，指的是把采集阶段封包好的内容传输到服务器的过程。其实就是将现场的视频信号传到网络的过程。
“推流”对网络要求比较高，如果网络不稳定，直播效果就会很差，观众观看直播时就会发生卡顿等现象，观看体验很是糟糕。
要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。
最后通过一定的Qos算法将音视频流数据推送到网络端，通过CDN进行分发。
提个问题： Qos算法是啥？自己下去研究吧
在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。
另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。
视频一开始会由两个端采集，一个是视频输入口，是一个音频输入口。然后，采集的数据会分别进行相关处理，简而言之就是，将视频/音频流，通过一定的手段转换为比特流。最终，将这里比特流以一定顺序放到一个盒子里进行存放，从而生成我们最终所看到的，比如，mp4/mp3/flv 等等音视频格式
什么拉流
拉流是指服务器已有直播内容，根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据，进行拉取的过程。
拉流端的核心处理在播放器端的解码和渲染，在互动直播中还需集成聊天室、点赞和礼物系统等功能。
拉流端现在支持RTMP、HLS、HDL（HTTP-FLV）三种协议，其中，在网络稳定的情况下，对于HDL协议的延时控制可达1s，完全满足互动直播的业务需求。
RTMP 是 Adobe 的专利协议，开源软件和开源库都支持的比较好，延时一般在1-3秒。
HLS 是苹果提出的基于HTTP的流媒体传输协议，优点是跨平台性比较好，HTML5可以直接打开播放，移动端兼容性良好，但是缺点是延迟比较高。
对于 WEB H5 端拉流直播 建议还是使用 HLS ，兼容性较好，延迟其实还好，谁叫你不用APP呢。
关于web H5 用flash 推流没有声音问题
这个问题很多云厂商都会有，现在解决方案是，不要使用 flash 播放器推流了，如果是WEB端直播的话，直接建议使用 开源免费的软件 OBS 进行推流，在自己后台管理端，进行房间聊天回复，等操作。
至于OBS如何美颜：
2. 协议介绍：
国内常见的直播协议有几个：RTMP、HLS、HTTP-FLV
HLS
HLS 全称是 HTTP Live Streaming。这是 Apple 提出的直播流协议。目前，IOS 和 高版本 Android 都支持 HLS。
HLS 主要的两块内容是 .m3u8 文件和 .ts 播放文件。接受服务器会将接受到的视频流进行缓存，然后缓存到一定程度后，会将这些视频流进行编码格式化，同时会生成一份 .m3u8 文件和其它很多的 .ts 文件。
其中 .m3u8 作为索引文件（确保包的顺序）
跨平台性比较好，HTML5可以直接打开播放，移动端兼容性良，就是延迟比较高。
HLS 支持的功能，并不只是分片播放（专门适用于直播），它还包括其他应有的功能。
- 使用 HTTPS 加密 ts 文件
- 快/倒放
- 广告插入
- 不同分辨率视频切换
HLS 的弊端：
由于 HLS 是基于 HTTP 的，所以，它关于 HTTP 的好处，我们大部分都了解，比如，高兼容性，高可扩展性等。不过正由于是 HTTP 协议，所以会在握手协议上造成一定的延迟性。HLS 首次连接时，总共的延时包括：
- TCP 握手，
- m3u8 文件下载，
- m3u8 下的 ts 文件下载。
总而言之，HLS 之所以能这么流行，关键在于它的支持度是真的广，所以，对于一般 H5 直播来说，应该是非常友好的。
RTMP：
RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议
Adobe公司为 Flash 播放器和服务器之间音频、视频和数据传输开发的私有协议,未完全公开。
纯 RTMP 使用 TCP 连接，默认端口为 1935（有可能被封）。
既然是 Adobe 公司开发的（算吧），那么，该协议针对的就是 Flash Video，即，FLV。
不过，在移动端上，Flash Player 已经被杀绝了，那为啥还会出现这个呢？
因为它主要是针对 PC 端的。
RTMP 出现的时候，还是 零几 年的时候，IE 还在大行其道，Flash Player 也并未被各大浏览器所排斥。那时候 RTMP 毋庸置疑的可以在视频界有自己的一席之地。
RTMP 由于借由 TCP 长连接协议，所以，客户端向服务端推流这些操作而言，延时性很低。
它会将上传的流分成不同的分片，这些分片的大小，有时候变，有时候不会变。
默认情况下就是，64B 的音频数据 + 128B 的视频数据 + 其它数据（比如 头，协议标签等）。
但 RTMP 具体传输的时候，会将分片进一步划分为包，即，视频包，音频包，协议包等。因为，RTMP 在进行传输的时候，会建立不同的通道，来进行数据的传输，这样对于不同的资源，对不同的通道设置相关的带宽上限。
该协议是一个基于TCP的协议族，是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。
支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。
现在推流协议各大云厂商基本都是直接支持 rtmp 。
拉流用 rtmp 的话就不太现实了，现在对 flash 支持都不友好了。
HDL (HTTP-FLV)
HTTP-FLV 和 RTMPT 类似，都是针对于 FLV 视频格式做的直播分发流。
但，两者有着很大的区别：
相同点：
- 两者都是针对 FLV 格式
- 两者延时都很低
- 两者都走的 HTTP 通道
不同点：
HTTP-FLv
- 直接发起长连接，下载对应的 FLV 文件
- 头部信息简单
RTMPT
- 握手协议过于复杂
- 分包，组包过程耗费精力大
因为 RTMP 发的包很容易处理，通常 RTMP 协议会作为视频上传端来处理，然后经由服务器转换为 FLV 文件，通过 HTTP-FLV 下发给用户。
