我的原文地址：http://www.xiaoniuzai.cn/2016/10/07/%E7%9B%B4%E6%92%AD%E6%B5%81%E7%A8%8B/
主播端
视频编码格式： H.264，H.265
音频编码格式： AAC， HE-AAC
编码的意义
- 原始视频数据存储空间大，一个 1080P 的 7 s 视频需要 817 MB
- 原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟
基本原理
主要就是去除冗余
- 空间冗余：图像相邻像素之间有较强的相关性
- 时间冗余：视频序列的相邻图像之间内容相似
- 编码冗余：不同像素值出现的概率不同
- 视觉冗余：人的视觉系统对某些细节不敏感
- 知识冗余：规律性的结构可由先验知识和背景知识得到
视频容器
所谓容器，就是把编码器生成的多媒体内容（视频，音频，字幕，章节信息等）混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条（当然这种情况下有的播放器会话比较长的时间临时创建索引），而且如果你不自己去手动另外载入音频就没有声音。
网络协议
| 全称 | 协议本质 | 原理 | 延迟 | |
|---|---|---|---|---|
| RTMP | Real Time Messaging Protocol | 长连接TCP | 每个时刻的数据收到后立刻转发 | 1~3s |
| HLS | HTTP Live Streaming | 短连接HTTP | 集合一段时间数据，生成ts视频文件，更新m3u8索引 | 10~20s |
| HTTP-FLV | RTMP over HTTP | 长链接HTTP | 每个时刻的数据收到后立刻转发，但是使用HTTP协议 | 1~3s |
HTTP Live Streaming
- .ts + m3u8 index file 切割视频为3个ts，每个ts 10s 所以延迟20~30s
- 基于HTTP，3次tcp握手，HTTP协议头，消耗大
- 平滑切换码率
- 基于HTTP可以避免防火墙或者代理问题
- 在ios/android的webkit浏览器内核可以播放
Real Time Messaging Protocol
- 数据流向不会产生类似HLS的ts文件
- 基于TCP，保持长连接，避免握手链接
- 跨平台差，需要flash player
总结
流程：主播端采集 -> 主播端编码 -> RTMP协议上传视频 -> 流媒体服务器解码，转码 -> 使用不同的流媒体格式，flv or m3u8 -> 使用不同的推流协议HLS or RTMP over HTTP 推送