关于直播的技术文章不少,成体系的不多。我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面、深入地了解视频直播技术,更好地技术选型。

直播技术之编码和封装

视频编码是本系列一个重要的部分,如果把整个流媒体比喻成一个物流系统,那么编解码就是其中配货和装货的过程,这个过程非常重要,它的速度和压缩比对物流系统的意义非常大,影响物流系统的整体速度和成本。同样,对流媒体传输来说,编码也非常重要,它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本

关于直播的技术文章不少,成体系的不多。我们将用七篇文章,更系统化地介绍当下大热的视频直播各环节的关键技术,帮助视频直播创业者们更全面、深入地了解视频直播技术,更好地技术选型。

直播:直播技术之编码和封装,移动开发。视频编码是视频直播技术系列文章的第三篇,是本系列一个非常重要的部分,是移动开发必修的基础课程,本篇文章从理论到实践一网打尽主流编码器。

视频编码的意义

原始视频数据存储空间大,一个 1080P 的 7 s 视频需要 817 MB
原始视频数据传输占用带宽大,10 Mbps 的带宽传输上述 7 s 视频需要 11
分钟
而经过 H.264 编码压缩之后,视频大小只有 708 k ,10 Mbps 的带宽仅仅需要
500 ms
,可以满足实时传输的需求,所以从视频采集传感器采集来的原始视频势必要经过视频编码。

视频编码是视频直播技术系列文章的第三篇,是本系列一个非常重要的部分,是移动开发必修的基础课程,本篇文章从理论到实践一网打尽主流编码器。

直播:直播技术之编码和封装,移动开发。如果把整个流媒体比喻成一个物流系统,那么编解码就是其中配货和装货的过程,这个过程非常重要,它的速度和压缩比对物流系统的意义非常大,影响物流系统的整体速度和成本。同样,对流媒体传输来说,编码也非常重要,它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。

基本原理

那为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢?在讲技术之前我们应先建立视频即连续图片的概念。

核心思想就是去除冗余信息:

  • 空间冗余:一张图片相邻像素之间有较强的相关性
  • 时间冗余:视频序列的相邻图片之间内容相似
  • 编码冗余:不同像素值出现的概率不同
  • 视觉冗余:人的视觉系统对某些细节不敏感
  • 知识冗余:规律性的结构可由先验知识和背景知识得到

直播:直播技术之编码和封装,移动开发。视频本质上讲是一系列图片连续快速的播放,所以对视频压缩最简单的方式就是对每一帧图片进行压缩,例如比较古老的
MJPEG
编码就是对视频中每帧图片进行压缩,这种编码方式只有帧内编码,利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片,采用
JPEG
的编码格式对图片进行压缩,这种编码只考虑了一张图片内的冗余信息压缩,如图
1,绿色的部分就是当前待编码的区域,灰色就是尚未编码的区域,绿色区域可以根据已经编码的部分进行预测(绿色的左边,下边,左下等)。

直播 1

但是帧和帧之间因为时间的相关性,后续开发出了一些比较高级的编码器可以采用帧间编码,简单点说就是通过搜索算法选定了帧上的某些区域,然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式,通过下面两个图
2
连续帧我们可以看到,滑雪的同学是向前位移的,但实际上是雪景在向后位移,P
帧通过参考帧(I 或其他 P
帧)就可以进行编码了,编码之后的大小非常小,压缩比非常高。

关于帧的参考连接

直播 2

可能有同学对这两张图片怎么来的感兴趣,这里用了 FFmpeg
的两行命令来实现,具体 FFmpeg 的更多内容请看后续章节:

  • 第一行生成带有移动矢量的视频
  • 第二行把每一帧都输出成图片

使用命令

ffmpeg  -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4

ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'

   

除了空间冗余和时间冗余的压缩,主要还有编码压缩和视觉压缩,下面是一个编码器主要的流程图:

直播 3

图 3、图 4 两个流程,图 3 是帧内编码,图 4
是帧间编码,从图上看到的主要区别就是第一步不相同,其实这两个流程也是结合在一起的,我们通常说的
I 帧和 P 帧就是分别采用了帧内编码和帧间编码。

如果把整个流媒体比喻成一个物流系统,那么编解码就是其中配货和装货的过程,这个过程非常重要,它的速度和压缩比对物流系统的意义非常大,影响物流系统的整体速度和成本。同样,对流媒体传输来说,编码也非常重要,它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。

本系列文章大纲如下,想复习之前文章的直接点击直达链接:

编码器的选择

直播:直播技术之编码和封装,移动开发。前面梳理了一下编码器的原理和基本流程,编码器经历了数十年的发展,已经从开始的只支持帧内编码演进到现如今的
H.265 和 VP9
为代表的新一代编码器,就目前一些常见的编码器进行分析,带大家探索一下编码器的世界。

本系列文章大纲如下,想复习之前文章的直接点击直达链接:

(一)采集

H.264

简介

H.264/AVC项目意图创建一种视频标准。与旧标准相比,它能够在更低带宽下提供优质视频(换言之,只有
MPEG-2,H.263 或 MPEG-4 第 2
部分的一半带宽或更少),也不增加太多设计复杂度使得无法实现或实现成本过高。另一目的是提供足够的灵活性以在各种应用、网络及系统中使用,包括高、低带宽,高、低视频分辨率,广播,DVD
存储,RTP/IP 网络,以及 ITU-T 多媒体电话系统。

H.264/AVC
包含了一系列新的特征,使得它比起以前的编解码器不但能够更有效的进行编码,还能在各种网络环境下的应用中使用。这样的技术基础让
H.264 成为包括 YouTube
在内的在线视频公司采用它作为主要的编解码器,但是使用它并不是一件很轻松的事情,理论上讲使用
H.264 需要交纳不菲的专利费用。

专利许可

和 MPEG-2 第一部分、第二部分,MPEG-4第二部分一样,使用 H.264/AVC
的产品制造商和服务提供商需要向专利的持有者支付专利许可费用。这些专利许可的主要来源是一家称为
MPEG-LA LLC 的私有组织,该组织和 MPEG
标准化组织没有任何关系,但是该组织也管理著 MPEG-2
第一部分系统、第二部分视频、MPEG-4
第二部分视频和其它一些技术的专利许可。
其他的专利许可则需要向另一家称为 VIA Licensing
的私有组织申请,这家公司另外也管理偏向音频压缩的标准如 MPEG-2 AAC 及
MPEG-4 Audio 的专利许可。

H.264 的开源实现

openh264是思科实现的开源H.264编码程序,虽然 H.264
需要交纳不菲的专利费用,但是专利费有一个年度上限,思科把 OpenH264
实现的年度专利费交满后,OpenH264 事实上就可以免费自由的使用了。

x264是一个采用GPL授权的视频编码自由软件。x264
的主要功能在于进行H.264/MPEG-4
AVC的视频编码,而不是作为解码器(decoder)之用。

除去费用问题比较来看:
openh264 CPU 的占用相对 x264低很多
openh264 只支持 baseline profile,x264 支持更多 profile

(一)采集

(二)处理

HEVC/H.265

简介

高效率视频编码(High Efficiency Video
Coding,简称HEVC)是一种视频压缩标准(也叫H.265),被视为是 ITU-T
H.264/MPEG-4 AVC 标准的继任者。2004 年开始由 ISO/IEC Moving Picture
Experts Group(MPEG)和 ITU-T Video Coding Experts Group(VCEG)作为
ISO/IEC 23008-2 MPEG-H Part 2 或称作 ITU-T H.265 开始制定。第一版的
HEVC/H.265 视频压缩标准在 2013 年 4 月 13
日被接受为国际电信联盟(ITU-T)的正式标准。HEVC
被认为不仅提升视频质量,同时也能达到 H.264/MPEG-4 AVC
两倍之压缩率(等同于同样画面质量下比特率减少了 50%),可支持 4K
分辨率甚至到超高清电视(UHDTV),最高分辨率可达到
8192×4320(8K分辨率)。

专利许可

HEVC要求所有包括苹果、YouTube、Netflix、Facebook、亚马逊等使用 H.265
技术的内容制造商上缴内容收入的
0.5%作为技术使用费,而整个流媒体市场每年达到约 1000
亿美元的规模,且不断增长中,征收
0.5%绝对是一笔庞大的费用。而且他们还没有放过设备制造商,其中电视厂商需要支付每台
1.5 美元、移动设备厂商每台 0.8
美元的专利费。他们甚至没有放过蓝光设备播放器、游戏机、录像机这样的厂商,这些厂商必须支付每台
1.1 美元的费用。

H.265/HEVC的开源实现

libde265 HEVC 由 struktur 公司以开源许可证 GNU LesserGeneral Public
License (LGPL)
提供,观众可以较慢的网速下欣赏到最高品质的影像。跟以前基于H.264标准的解码器相比,libde265
HEVC 解码器可以将您的全高清内容带给多达两倍的受众,或者减少 50%
流媒体播放所需要的带宽。

x265 是由 MulticoreWare 开发,采用 GPL 协议开源。

(二)处理

(三)编码和封装

VP8

简介

VP8 是一个开放的视频压缩格式,最早由 On2 Technologies 开发,随后由
Google 发布。同时 Google 也发布了 VP8 编码的实做库:libvpx,以 BSD
授权条款的方式发行,随后也附加了专利使用权。而在经过一些争论之后,最终
VP8 的授权确认为一个开放源代码授权。

目前支持 VP8 的网页浏览器有 Opera、Firefox 和 Chrome。

专利许可

2013 年三月,Google 与 MPEG LA 及 11 个专利持有者达成协议,让Google 获取
VP8 以及其之前的 VPx 等编码所可能侵犯的专利授权,同时 Google
也可以无偿再次授权相关专利给 VP8 的用户,此协议同时适用于下一代 VPx
编码。至此 MPEG LA 放弃成立 VP8 专利集中授权联盟,VP8
的用户将可确定无偿使用此编码而无须担心可能的专利侵权授权金的问题。

VP8的开源实现

libvpx 是 VP8 的唯一开源实现,由 On2 Technologies 开发,Google
收购后将其开放源码,License 非常宽松可以自由使用。

(三)编码和封装

(四)推流和传输

VP9

简介

VP9 的开发从 2011 年第三季开始,目标是在同画质下,比 VP8 编码减少
50%的文件大小,另一个目标则是要在编码效率上超越 HEVC 编码。

2012 年 12 月 13 日,Chromium 浏览器加入了 VP9 编码的支持。Chrome
浏览器则是在 2013 年 2 月 21 日开始支持 VP9 编码的视频播放。

Google 宣布会在 2013 年 6 月 17 日完成 VP9 编码的制定工作,届时Chrome
浏览器将会把 VP9 编码默认引导。2014 年 3 月 18 日,Mozilla 在 Firefox
浏览器中加入了 VP9 的支持。

2015 年 4 月 3 日,谷歌发布了 libvpx1.4.0 增加了对 10 位和 12
位的比特深度支持、4:2:2 和 4:4:4 色度抽样,并 VP9 多核心编/解码。

专利许可

VP9 是一个开放格式、无权利金的视频编码格式。

VP9 的开源实现

libvpx 是 VP9 的唯一开源实现,由 Google 开发维护,里面有部分代码是 VP8
和 VP9 公用的,其余分别是 VP8 和 VP9 的编解码实现。

(四)推流和传输

(五)现代播放器原理

VP9 和 H.264 和 HEVC 比较

直播 4

(五)延迟优化

(六)延迟优化

HEVC 和 H.264 在不同分辨率下的比较

跟 H.264/MPEG-4 相比,HEVC 的平均比特率减低值为:

直播 5

可见码率下降了 60% 以上

  • HEVC (H.265) 对 VP9 和 H.264 在码率节省上有较大的优势,在相同 PSNR
    下分别节省了 48.3% 和 75.8%
  • H.264 在编码时间上有巨大优势,对比 VP9 和 HEVC(H.265) ,HEVC 是 VP9
    的6倍,VP9 是 H.264 的将近 40 倍

(六)现代播放器原理

(七)SDK 性能测试模型

FFmpeg

谈到视频编码相关内容就不得不提一个伟大的软件包 — FFmpeg。

FFmpeg
是一个自由软件,可以运行音频和视频多种格式的录影、转换、流功能,包含了
libavcodec ——这是一个用于多个项目中音频和视频的解码器库,以及
libavformat ——一个音频与视频格式转换库。

FFmpeg 这个单词中的 FF 指的是 Fast Forward。有些新手写信给 FFmpeg
的项目负责人,询问 FF 是不是代表 Fast Free 或者 Fast Fourier
等意思,FFmpeg 的项目负责人回信说:「Just for the record, the original
meaning of FF in FFmpeg is Fast Forward…」

这个项目最初是由 Fabrice Bellard 发起的,而现在是由 Michael Niedermayer
在进行维护。许多FFmpeg的开发者同时也是 MPlayer 项目的成员,FFmpeg 在
MPlayer 项目中是被设计为服务器版本进行开发。

FFmpeg 下载地址是 :

(七)SDK 性能测试模型

视频编码的意义

  • 原始视频数据存储空间大,一个 1080P 的 7 s 视频需要 817 MB
  • 原始视频数据传输占用带宽大,10 Mbps 的带宽传输上述 7 s 视频需要 11
    分钟

而经过 H.264 编码压缩之后,视频大小只有 708 k ,10 Mbps 的带宽仅仅需要
500 ms
,可以满足实时传输的需求,所以从视频采集传感器采集来的原始视频势必要经过视频编码。

FFmpeg录屏

通过一个小例子看一下怎么在 Mac OS 下面使用 FFmpeg 进行录屏:

输入:

ffmpeg -f avfoundation -list_devices true -i ""

输出:

[AVFoundation input device @ 0x7fbec0c10940] AVFoundation video devices:
[AVFoundation input device @ 0x7fbec0c10940] [0] FaceTime HD Camera
[AVFoundation input device @ 0x7fbec0c10940] [1] Capture screen 0
[AVFoundation input device @ 0x7fbec0c10940] [2] Capture screen 1
[AVFoundation input device @ 0x7fbec0c10940] AVFoundation audio devices:
[AVFoundation input device @ 0x7fbec0c10940] [0] Built-in Microphone

给出了当前设备支持的所有输入设备的列表和编号,我本地有两块显示器,所以 1
和 2 都是我屏幕,可以选择一块进行录屏。


基本原理

那为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢?
核心思想就是去除冗余信息:

  • 空间冗余:图像相邻像素之间有较强的相关性
  • 时间冗余:视频序列的相邻图像之间内容相似
  • 编码冗余:不同像素值出现的概率不同
  • 视觉冗余:人的视觉系统对某些细节不敏感
  • 知识冗余:规律性的结构可由先验知识和背景知识得到

视频本质上讲是一系列图片连续快速的播放,最简单的压缩方式就是对每一帧图片进行压缩,例如比较古老的
MJPEG
编码就是这种编码方式,这种编码方式只有帧内编码,利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片,采用
JPEG
的编码格式对图片进行压缩,这种编码只考虑了一张图片内的冗余信息压缩,如图
1,绿色的部分就是当前待编码的区域,灰色就是尚未编码的区域,绿色区域可以根据已经编码的部分进行预测(绿色的左边,下边,左下等)。

图1

但是帧和帧之间因为时间的相关性,后续开发出了一些比较高级的编码器可以采用帧间编码,简单点说就是通过搜索算法选定了帧上的某些区域,然后通过计算当前帧和前后参考帧的向量差进行编码的一种形式,通过下面两个图
2
连续帧我们可以看到,滑雪的同学是向前位移的,但实际上是雪景在向后位移,P
帧通过参考帧(I 或其他 P
帧)就可以进行编码了,编码之后的大小非常小,压缩比非常高。

图 2

可能有同学对这两张图片怎么来的感兴趣,这里用了 FFmpeg
的两行命令来实现,具体 FFmpeg 的更多内容请看后续章节:

  • 第一行生成带有移动矢量的视频
  • 第二行把每一帧都输出成图片

ffmpeg  -flags2 +export_mvs -i tutu.mp4 -vf codecview=mv=pf+bf+bb tutudebug2.mp4

ffmpeg -i tutudebug2.mp4 'tutunormal-%03d.bmp'

除了空间冗余和时间冗余的压缩,主要还有编码压缩和视觉压缩,下面是一个编码器主要的流程图:

图 3

图 4

图 3、图 4 两个流程,图 3 是帧内编码,图 4
是帧间编码,从图上看到的主要区别就是第一步不相同,其实这两个流程也是结合在一起的,我们通常说的
I 帧和 P 帧就是分别采用了帧内编码和帧间编码。

查看当前的编解码器

查看H.264

输入:

ffmpeg -codecs | grep 264

输出:

DEV.LS h264  H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vda ) (encoders: libx264 libx264rgb )

查看VP8

输入:

ffmpeg -codecs | grep vp8

输出:

DEV.L. vp8  On2 VP8 (decoders: vp8 libvpx ) (encoders: libvpx )

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图