探索多媒体直播技术| 青训营笔记
这是我参与「第四届青训营 」笔记创作活动的第2天
探索多媒体直播技术
了解视频基本元素,视频压缩,视频推拉流协议。
1. 视频的基本元素
-
像素定义
像素是指再由一个数字序列表示的图像中的一个最小单位。通常表现为一个小方格。 每个像素有自己的颜色值,一般为RGB三原色来表示。
-
RGB三原色
每种颜色都可以用三个变量来表示-红色绿色以及蓝色的强度。记录及显示彩色图像时,RGB是最常见的一种方案。他们的取值,RGB分别从0-255,一共256个等级。
-
分辨率
分辨率是指从纵横方向的像素数量,一般表示为:宽 * 高(or 长 * 宽),720 * 1080等。
-
码率、比特率:
表示单位时间内传送bit的数目,单位bps,表示是单位时间播放连续的媒体如压缩后的音频视频的bit数量,也称码流。这种bps的单位电信领域上表示速度,就是我们常说的网速了。比如100Mbps。越高的比特率需要越高的带宽来支撑,否则会到来卡顿、成本等问题。太低的比特率,可能会到时视频画面过度压缩模糊不清。
-
帧
帧(Frame)就是视频或者动画中的每一张画面,而视频和动画特效就是由无数张画面组合而成,每一张画面都是一帧。
-
帧率
帧率(Frame Rate) 每秒传输帧数通俗来讲就是指动画或者视频的画面数、帧率。每秒钟帧数越多,所显示的动作就越流畅。FPS也可以理解为我们常说的“刷新率”。当刷新率太低时我们肉眼都能感觉到屏幕的闪烁、不连贯,对图像显示效果和视觉感官产生不好的影响。
-
轨道/流
2. 视频压缩
-
帧内压缩 / 空间压缩
帧内(Intraframe)压缩也称为空间压缩(Spatial compression) 当压缩一帧图像时,仅考虑本帧的数据而不考虑相邻帧之间的冗余信息,这实际上与静态图像压缩类似。帧内一般采用有损压缩算法,达不到很高的压缩比。
-
帧间压缩 / 时间压缩
帧间压缩(Interframe compression)也称为时间压缩(Temporal compression),是基于许多视频或动画的连续前后两帧具有很大的相关性(即连续的视频其相邻帧之间具有的冗余信息)的特点来实现的。 通过比较时间轴上不同帧之间的数据实施压缩,进一步提高压缩比,一般是无损压缩。
- I-frame:Intra-frame 帧内帧
- P-frame:Predicted Frame 前向预测帧
- B-frame:Bi-Directional frame 由于B帧可以参考和插入在它之前和之后发生的两个(或更多)帧(在时间维度上),所以它可以显著降低帧的大小,同时保持视频质量。B帧能够利用空间冗余和时间冗余(未来的帧和过去的帧),这是得他在视频压缩中非常有用。
视频改变播放进度后,如果不在同一个GOP中,需要从新位置所在的GOP的I帧开始解码拖动后起播所需的耗时取决于位置在GOP 中的位置,越靠前能越快响应。
-
不同场景对GOP的设置也不一样
- 视频点播:节流带宽,高压缩率,会使用B帧
- 直播:低延迟,不适应B帧
- 视频编辑:提高响应,个别会使用I帧
-
视频编码格式 H264 VS H265
H265 压缩比更高,不要更多算力 H264 AVC 更普及 H265 HEVC 更小体积
3. 直播推拉流协议
-
CDN : Content Delivery Network
建立并覆盖在Internet之上,有分布在不同区域的边缘节点服务器群组成的分布式网络。通过只能调度将用户请求到最接近用户的服务节点,降低用户访问延迟,提高可用性。
- 边缘节点:指在靠近用户的网络边缘侧构建的业务平台,提供存储、计算、网络等资源。将部分关键业务应用下沉到接入网络边缘,以减少网络传输和多级转发带来的宽度和时延损耗
-
封装格式:MP4
是指按照一定的规则,将视频数据、音频数据等,放到一个文件中。 常见的MKV、AVI以及本文介绍的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组成。 tagy又可以分为三类:audio,video,script,分别代表音频流,视频流,脚本流(关键字或者文件信息之类)
-
推拉流协议
- RTMP:Real-Time Messaging Protocol
- HTTP-FLV:HTTP + FLV
- HLS:HTTP Live Streaming
流媒体接入,也就是推流,应该使用RTMP协议。流媒体系统内部分使用RTMP协议。因为内网系统网络状况好,使用RTMP更能发挥它的高效本领。在PC上,尽量使用RTMP协议,因为PC基本都安装了Flash播放器,直播效果要更好。移动端的瓦那个也播放器最好使用HLS协议。 IOS要使用HLS技术相比,因为不支持RTMP协议。点播系统最好使用HLS协议。因为点播没有实时互动需求,延迟大一些是可以接受的,并且可以在浏览器上直接观看。首先,与HLS技术相比,RTMP协议在输出时延上要比HLS小得多。主要原因在于HLS时基于切片(几秒钟视频的小文件),然后缓存的技术,这种技术从原理上就比直接进行数据传输慢很多,事实上也证明了这一点。 其次,想对于RTP协议,RTMP底层时基于TCP协议的,所以它不用考虑数据丢包、乱序、网络抖动等问题,极大地减少了开发人员的工作量;而使用RTP协议,网络质量的保障需要自己来完成。
-
推流协议
实时消息协议(RTMP)也称实时消息传输协议。,时最初由Macromedia未通过互联网在Flash播放器与一个服务器之间传输流媒体音频视频和数据而开发的一个专有协议。后被Adobe公司收购。
优势
- 基于tcp协议
- 技术成熟,Ffmpeg项目中有rtmp库
- 低延迟
劣势
- 停止更新
- 规范上没有支持H265
- 使用 1935 端口,会被防火墙阻碍