在流媒体服务器搭建以及使用的过程中, 整理的一些概念性知识
什么是分辨率
SMPTE(美国电影电视工程师协会) 规定: 720P 是高等级高清数字电视的格式标准 也就是 1280 * 720
数字信号电视扫描线根据不同清晰度分为: 1080p 720p 1080i(隔行扫描, 效果比 720 好, 没有 1080p 好)
常见的相机像素:
常见的分辨率:
1
2
3
4
5
6
7
8
9
D1：480i格式，和NTSC模拟电视清晰度相同，行频为15.25kHz
D2：480P格式，和逐行扫描DVD规格相同，行频为31.5kHz
D3：1080i格式，分辨率为1920×1080i/60Hz，行频为33.75kHz
D4：720p格式，分辨率为1280×720p/60Hz，行频为45kHz
D5：1080p格式，分辨率为1920×1080逐行扫描，专业格式
4K 分辨率: 指水平方向上的像素点大概有 4K 个, 并不是扫描行, 常见的 4K 分辨率为 4096×2160, 或 16:9 的比例 3840×2160 , 相当于: 1920 * 2 × 1080 * 2 翻了四倍
1080p 换算成流的大小: 1920 * 1080 = 2073600 个像素点 * RGB(三字节) = 6220800 byte = 6075kb = 6MB (在未使用图像压缩算法之前的大小) 经过图像压缩算法 H.264 压缩后, 大概为几百 K
帧: 显示器从头到尾渲染一次的动作, 相当于一次图片渲染, 连续帧组成了动画
什么是码率
码率就是 单位时间内传输的比特位 kbps
码率越高, 画面取样率越高, 越接近无损
码率KBPS = 文件大小(kb) * 8 (byte -> bit) / 1000
码率和带宽的换算: 6000 码率大概能支持 1080p 60 帧 约等于 6MB 的带宽
音视频压缩技术
RGB三颜色可渲染人眼观察到的宏观世界, 在计算机内, 一组 RGB 需要使用三字节来表示(255,255,255)
高分辨率下, 一帧图像能达到几百 MB, 如果不使用压缩技术, 那么对网络造成的压力是无比巨大的, 人们也就实现不了视频相关的互联网服务
对于音频, 也是同样的道理, 高清原声的音频, 体积也非常的大
音视频之所以能被压缩, 因为其具备以下的特点:
1
2
3
4
时域冗余：视频相邻的两帧之间内容相似，存在运动关系
空域冗余：视频的某一帧内部的相邻像素存在相似性 音频则为相似的波形等
编码冗余：不同数据出现的概率不同
视觉冗余：观众的视觉系统对视频中不同的部分敏感度不同
通过预测帧来进行双向预测, 抽取关键帧来进行压缩
常见的视频编码技术: H.264, 常见的音频编码技术: ACC
推拉流协议
常见的推拉流协议 RTMP、HTTP-FLV、HLS
其中 推流主要为:RTMP
拉流主要为 HTTP-FLV HLS 属于苹果侧拉流协议, 在苹果系列产品中常见
1
2
3
4
5
6
7
8
9
10
11
12
13
RTMP: Real Time Messaging Protocol，即实时消息传送协议, Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的私有协议。
工作在 TCP 之上的明文协议，默认使用端口 1935。协议中的基本数据单元成为消息（Message），传输的过程中消息会被拆分为更小的消息块（Chunk）单元。
最后将分割后的消息块通过 TCP 协议传输，接收端再反解接收的消息块恢复成流媒体数据。
RTMP 是专为流媒体开发的协议，对底层的优化比其它协议更加优秀，同时它 Adobe Flash 支持好，基本上所有的编码器（摄像头之类）都支持 RTMP 输出
FLV (Flash Video): 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。
整个 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 组成。HTTP-FLV 依靠 MIME 的特性，根据协议中的 Content-Type 来选择相应的程序去处
理相应的内容，使得流媒体可以通过 HTTP 传输。
HLS (HTTP Live Streaming) 则是苹果公司基于 HTTP 的流媒体传输协议。主要应用于 iOS 设备，包含(iPhone, iPad, iPod touch) 以及 Mac OSX
提供音视频直播服务和录制内容（点播）等服务。HLS 最大的不同在于它并不是一下请求完整的数据流。它会在服务器端将流媒体数据切割成连续的时长较短的 ts 小文件，
并通过 M3U8 索引文件按序访问 ts 文件。客户端只要不停的按序播放从服务器获取到的文件，从而实现播放音视频。
直播细分
1
2
1.主播对外展示, 与观众通过弹幕交互
2.主播与观众连麦, 或多人连麦(视频会议也包括于此)
RTMP 为主要的流媒体传输协议, 但是对延迟容忍性低的 连麦, 以及多人互动, 使用 rtmp 来解决, 不仅延迟问题难以解决, 对网络负载也产生较大的影响
另外 RTMP 可以通过 P2P 技术来达到减低服务器负载的目的(观看相同的视频源)
使用 WEBRTC 可以解决上述延迟以及带宽问题:
1
2
3
4
5
6
7
8
9
10
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。
它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。
优点
·W3C 标准，主流浏览器支持程度高
·Google 在背后支撑，并在各平台有参考实现
·底层基于 SRTP 和 UDP，弱网情况优化空间大
·可以实现点对点通信，通信双方延时低
缺点
·ICE,STUN,TURN 传统 CDN 没有类似的服务提供
基于WebRTC的P2P的连麦是比较简单的，最简单的思路，主播和粉丝P2P通了之后，主播将两路视频或者合成一路直接推送到SRS服务器上，供粉丝观看即可，连麦者获取主播视频本地观看。 多人连麦可需要稍微复杂的服务架构设计和实现，有较大的难度，保证实时和稳定以及质量。