直播推拉流
封装格式
按照一定的规则，把视频数据、音频数据放到一个文件中
MP4
容器协议
Moov：Movie Box，存储 mp4 的 metadata，一般位于mp4文件的开头。(为达到秒播效果，会记录很多信息在该文件)
mvhd：Movie Header Box，mp4文件的整体信息，比如创建时间、文件时长等
trak：Track Box，一个mp4可以包含一个或多个轨道（比如视频轨道、音频轨道）
Stbl：Sample Table Box
包含了这些媒体数据的索引以及时间信息
较大的层级结构
FLV
流式文件
FLV是一个二进制文件，由文件头（FLV header）和很多tag组成。
tag又可以分成三类:audio,video,script，分别代表音频流，视频流，脚本流（关键字或者文件信息之类）
由于没有一个记录信息的头的结构，所以在一开始不知道会播多久，且数据是链式可以一节节用Tag拼装起来，那么就可以用cdn不断分发下去，所以非常适合直播时候使用。
由于缺少头信息，所以在一般的播放器中，Flv是不支持拖拽的。需要支持拖拽的话就得遍历所有Tag之后记录其时间戳才能实现拖拽
CDN转发网络
定义：建立并覆盖在Internet 之上，由分布在不同区域的边缘节点服务器群组成的分布式网络。通过智能调度将用户请求到最接近用户的服务节点，降低用户访问延迟，提升可用性。
边缘节点：指在靠近用户的网络边缘侧构建的业务平台，提供存储、计算、网络等资源，将部分关键业务应用下沉到接入网络边缘，以减少网络传输和多级转发带来的宽度和时延损耗
- 点播：视频播放
- 直播看播：观众观看直播
- 推流：主播将数据发送到CDN网络
- 拉流：观众从CDN拉去直播数据
通信方案
推拉流协议方案
RTMP
推流
RTMP：实时消息协议（Real-Time Messaging Protocol）
也称实时消息传输协议，是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体、音频、视频和数据而开发的一个专有协议。后被 Adobe公司收购。
优势：
•基于 tcp 协议
•技术成熟，FFmpeg 项目中有 rtmp 库
•低延迟(5-10s)
劣势：
•停止更新
•规范上没有支持 H265
•使用 1935 端口，会被防火墙阻碍
当我们获取到RTMP数据的时候，褪去协议层，就可以很方便的直接得到FLV视频数据
拉流
为解决上述的缺点问题，拉流端使用下面的协议，该协议的封装可以在CDN完成然后再供用户拉流
HTTP-FLVFlash Video（简称FLV），是一种网络视频格式，用作流媒体格式。
协议友好，格式简单，便于分发。由于几乎所有设备都会支持HTTP请求协议，那么这个协议对拉流极为友好，也是业内使用最多的协议。
不转码的情况下直接转发即可，延迟较低
HLS
HTTP Live Streaming，缩写为HLS，是由苹果公司提出基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。
在开始一个流媒体会话时，客户端会下载一个包含元数据的扩展 M3U (m3u8) 播放列表文件，用于寻找可用的媒体流。
该协议把直播分成一段段小的视频文件(M3u8)，然后在后边就进行封装为一个个的 ts 格式的包，必要时候可以再度封装为 http 格式的包。
如果播放使用的是 HLS 协议，如图所示，假设服务端按照 3～10s 为单位来切片生成 ts 文件，则会直接导致播放的延时会达到 3～10s，这是该协议在延时方面的硬伤，如果对直播延时敏感，一般改用 RTMP 或者 HTTP-FLV 协议来拉直播流。
协议对比
推拉流流程
推流端
采集方式：摄像头、屏幕、图像采集卡等
图像处理的场景：美颜、绿幕、头饰 多使用 OpenGl
拉流端
音画同步
比较常用的策略是：视频同步到音频。(由于人对声音是更加敏感的)
因为音频是流式的，按照规律的匀速的速率去播放，才能显得更加 “平滑”，而视频的播放其实是一张一张图片进行刷新显示，它的刷新时间的调整相对而言更容易一些，用户肉眼的敏感度也更弱一些。
