直播技术栈梳理
我的原文地址: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 推送