在流媒体服务器搭建以及使用的过程中, 整理的一些概念性知识

什么是分辨率

SMPTE(美国电影电视工程师协会) 规定: 720P 是高等级高清数字电视的格式标准 也就是 1280 * 720

数字信号电视扫描线根据不同清晰度分为: 1080p 720p 1080i(隔行扫描, 效果比 720 好, 没有 1080p 好)

常见的相机像素:

image

常见的分辨率:

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, 如果不使用压缩技术, 那么对网络造成的压力是无比巨大的, 人们也就实现不了视频相关的互联网服务

对于音频, 也是同样的道理, 高清原声的音频, 体积也非常的大

音视频之所以能被压缩, 因为其具备以下的特点:

时域冗余:视频相邻的两帧之间内容相似,存在运动关系
空域冗余:视频的某一帧内部的相邻像素存在相似性  音频则为相似的波形等
编码冗余:不同数据出现的概率不同
视觉冗余:观众的视觉系统对视频中不同的部分敏感度不同

通过预测帧来进行双向预测, 抽取关键帧来进行压缩

常见的视频编码技术: H.264, 常见的音频编码技术: ACC

推拉流协议

常见的推拉流协议 RTMP、HTTP-FLV、HLS

其中 推流主要为:RTMP

拉流主要为 HTTP-FLV HLS 属于苹果侧拉流协议, 在苹果系列产品中常见

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.主播与观众连麦, 或多人连麦(视频会议也包括于此)

RTMP 为主要的流媒体传输协议, 但是对延迟容忍性低的 连麦, 以及多人互动, 使用 rtmp 来解决, 不仅延迟问题难以解决, 对网络负载也产生较大的影响

另外 RTMP 可以通过 P2P 技术来达到减低服务器负载的目的(观看相同的视频源)

使用 WEBRTC 可以解决上述延迟以及带宽问题:

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服务器上,供粉丝观看即可,连麦者获取主播视频本地观看。 多人连麦可需要稍微复杂的服务架构设计和实现,有较大的难度,保证实时和稳定以及质量。


相关文章:
⤧  上一篇 SPI 与 ContextClassLoader ⤧  下一篇 Maven 打包, 一文通透