慢慢慢慢

不积跬步
无以至千里

<在线视频技术精要> 摘录

一、在线视频行业

1.3 常见文件与编码格式

在市场上由于技术的发展和不同公司的竞争,产生出许多流行的文件格式,较著名的有WAV、MP3、RM、MPG、WMV、WMA、AVI、MOV、MP4、3GP、FLV、MKV、AC3、AMR、OGG、AAC、APE等。

音视频编码技术是视频行业存在的前提,视频信号数字化后占用大量的存储空间和数据带宽,高清视频的码率往往可以达到约200Mbit/s,以此推算120分钟的电影将占到180GB以上,无论从存储还是传输角度,都是一个难以接受的数字,而通常可以下载的高清电影视频,也不过是2~8GB大小,这其中依靠的就是音视频编码技术了。

所谓编码技术,实质是一种针对特定音视频格式内容压缩成另一种视频格式的方式。随着技术的发展,市场上常见的视频压缩技术有RV、VC-1、MPEG2、H.263、H.264、H.265、VP8、VP9等,音频压缩技术包含MP3、RA、AMR、AAC、Vorbis、AC3、APE等,而上述的文件格式,则定义了作为一个容器如何将视频和音频编码完成的内容封装在内的方法。

举例而言,一个MP4文件内,可能包含通过H.264技术编码的视频内容以及通过AAC技术编码的音频内容,而MP4文件如何规范视频、音频及其他信息在这单一文件内的存储方式,则被称作打包技术或封装技术。不同编码技术的出发点大体一致,都是为了让音视频内容的质量可以损失更小,压缩率更高,不同的文件封装技术则略有不同,有些是为了支持特定的编码技术,有些则希望通过支持多种不同的编码技术,成为较为通用的容器。

1.3.1 上古时代

(1)WAV
WAV,是微软开发的一种声音文件格式,常见的WAV文件和CD格式一样,具有44.1K的采样率[插图],16位采样位数[插图],并支持单声道或立体声[插图],即WAV文件的大小可以通过采样率×采样位数×声道×时间计算得出(需除以8,因为1字节=8Bit)。

(2)MP3
MP3,以WAV为代表的音频文件因为未经压缩,所以较少用来存储较长的声音内容,在20世纪末,大量音频文件使用MP3格式进行存储,下载和交换,提供较好的音质和压缩比率。MP3实质是对PCM数据中涉及的人类听觉不重要的部分进行舍弃,从而压缩得到较小的文件,它提供多种不同的bitrate(每秒所需数据)的选择,常见速率有128kbit/s、192kbit/s、320kbit/s等。

(3)RM、RMVB、RV、RA
RM即RealMedia,是RealNetworks公司创建的专用多媒体容器格式,文件扩展名多用“.rm”,通常用于RealVideo和RealAudio的结合,一般是CBR(固定码率)编码,RMVB则是RM的换代格式,支持可变码率。RM格式的主要特征在于不需要下载完整文件即可播出,并可以根据不同的网络传输速率制定不同的压缩比率,可见它一开始就定位在流媒体应用方面。

(4)MPG
MPG文件后缀名可以是“.mpg”或“.mpeg”,内含两种文件格式,即PS(Program Stream,节目流)和TS(Transport Stream,传输流),分别用于不同的场合,根据格式不同,后缀名也可能是“m2p”“.ps”或“.ts”。
TS格式则更适合网络传播,同样来自ISO/IEC 13818-1标准。在逻辑上,一个TS文件(或传输流)包含一组SubStream(即PES),可以是视频、音频、MJPEG或JPEG2000的图片、字幕或EPG(见图1-14)[插图]。每个流都被分解组装到188字节大小的包中,由于每个包都较小,可以容易部分地传输,各个流之间可以交错排布。

(5)WMV、WMA、ASF、MMS、AVI
WMV是一系列由微软开发的视频编码格式和文件格式,其中WMV version 9因为被许多地方选用而以VC-1编码格式之名为人熟知,微软为此专门开发了一种名为ASF的文件格式来存储,但后缀名既可能为“.asf”,也可能为“.wmv”。与之相伴,名为WMA的音频编码格式,能够以较MP3少1/3~1/2的码率存储相似音质的音频,通常后缀名为“.wma”。

AVI全称Audio Video Interleaved,是微软在很早便推出的多媒体文件格式,但因其良好的适应性,仍然被广泛使用。AVI可以支持非常广泛的音视频编码格式,包括较新的H.264、HE-AAC等。

1.3.2 “现代”格式

(1)MOV、MP4、3GP
MOV文件是苹果公司对多媒体行业的一大贡献,它又被称作QuickTime FileFormat,可以包含一个或多个Track,每个Track存储:视频、音频或字幕中的一种类型的数据,每个Track又由一个层次分明的Object结构组成(每个Object又叫Atom)。一个Atom可以包含其他Atom,也可以包含多媒体数据,但不能兼得。

MP4文件几乎完全基于QuickTime文件格式,它由标准ISO/IEC 14496-12规定,并且添加了extension,形成MPEG-4Part14(见图1-15)。MP4文件还常有另外一些文件名后缀,如“.mpa”,“.m4v”等。

在编码方式相同相同的情况下,.avi, .mkv, .mp4只是封装格式的区别,而封装格式是不影响画质的。就相当于你的100块钱折一下,或者两下,或者两下后不管是放在你的口袋里,钱包里还是存钱罐里都是100块钱。这里的100块钱就是就是视频数据,你把100块折一下,或者两下,或者两下就是编码格式,钱包,口袋,存钱罐就是封装格式。应用场景不一样而已。

视频中我们通常说的视频的格式,比如 .mp4, .mov, .wmv, .m3u8, .flv 等等被称为container。在一个视频文件中音频、视频数据是分开存储的,使用的压缩算法也不一样。其中container作为容器主要包含了video数据、audio数据、metadata(用于检索视音频payload格式等信息)。每个格式的封装格式不一样,比如FLV格式的基本单元是Tag,而MP4格式的基本单元是Box,辅助的meta信息用于检索找到对应的原始数据。

(2)FLV、F4V
这是一种随着Flash发展而发布的,适用于流媒体传输的视频格式,内部初始基于Sorenson公司的编码算法,也支持H.263及VP6等格式。由于YouTube、Hulu、优酷、土豆等网站早期均大量使用Flash技术,FLV文件也变得非常流行。与之配合,FLV文件的传输多使用RTMP协议,Adobe还提供免费的Flash MediaEncoder(Flash媒体编码器)帮助生成FLV格式的文件。

(3)MKV
随着互联网视频的流行,一种兼容多种媒体类型的容器格式(文件格式)流行开来,这就是Matroska,MKV即是Matroska系列中的一种格式,其后缀名多为“.mkv”,另有适用于单一音频的“.mka”文件和独立的字幕文件“.mks”。从概念上讲,MKV容器和MP4、AVI、ASF等处于同一层次,吸引开发者和用户注意之处是其免费和开源,它的最大特点就是支持多种不同类型编码的视频、音频、字幕,甚至包括章节、标签信息,还可以加上附件。此外,MKV支持EDC错误检测代码,意味着没有下载完成的MKV也可以播放,且容器本身占用的空间比其他格式还要略小。

(4)AC3
Dolby Digital格式,又称作AC3,是Dolby(杜比)公司开发的一系列有损或无损音频格式中的一种

(5)H.263、MPEG4
MPEG标准组织曾定义MPEG1、MPEG2、MPEG3和MPEG4格式,希望适应不同带宽和视频质量的要求,微软在1998年开发了第一个MPEG-4编码器,包括MSMPEG4v1、MS MPEG4v2和MS MPEG4v3系列,其中V3的画质有显著进步,曾经颇为流行的DivX即是盗版MS MPEG4v3并加入了一些特性得到的编码器。

H.263是ITU-T为视频会议设计的低码率视频编码标准,之后还有增加了新功能的H.263v2和H.263v3。H.263和MPEG4两种编码格式的设计存在很多相似之处,二者曾在世纪初满足了很多领域视频编码的需求,虽然现在被认为已经过时,在各个环节都被H.264和HEVC取代,然而还有一些仍在服役的设备和软件使用它们,还有被转码成较新格式或播放的需求。

(6)H.264(也叫 MPEG-4AVC)
标准MPEG4Part10,Advanced Video Coding中规定的编码格式,缩写为MPEG-4AVC,又称作H.264,是当前应用最为广泛的视频编码格式。编码格式基于较新的运动补偿的方式设计,第一个版本于2003年完成,陆续增加了多个新特性,其MPEG4AVC的名称来自于MPEG组织,而H.264的命名则延续了ITU-T社区的约定。

H.264之所以可以得到或许是历史上最广泛的应用,除了它代表近年来比较先进的视频压缩技术,很重要的因素在于其专利许可政策标准(价格)较低并具备很强的操作性。首先,AVC许可政策每台设备仅收取0.2美元的费用,远低于前一代MPEG-2格式的每终端约5美元的价格(2002年降价后也需要2.5美元),相比MPEG4,取消了按编解码时间收费。

H.264的许可政策对较小规模的使用完全免费,收费仅针对较大的设备出货量且存在封顶,这让商业模式变得非常灵活,例如思科可以开放其H.264视频编解码器的源代码,所有人都可以免费使用,就因为思科已经缴足了封顶的专利费用。对于点播服务,专利收费政策也十分友好,按次付费则仅对12分钟以上的内容收取终端用户付费的2%,如按月付费的会员制则在超过100万用户/年的情况下仅封顶收取10万美元。

不论是MPEG-4 AVC、MPEG-4 Part 10,还是ISO/IEC 14496-10,都是指H.264。

平时听到的H.264, H.265等视频编码标准被称为codec (COmpress and DECompress )。一个视频格式比如mp4可以使用任何标准化的压缩算法,这些信息都会被包含在一个视频文件的meta信息中来告诉播放器该用什么编解码算法来播放。

(7)H.265(也叫 HEVC)
High Efficiency Video Coding简称HEVC,又称作H.265。与H.264相似,两个不同名称分别来自于ISO/IEC MPEG工作组和ITU-T,目标是替代H.264成为新一代视频编码标准。HEVC在编码效率上较H.264有接近50%的提升,可以支持最高8K分辨率,当然作为代价,在编码方法上也更为复杂。与H.264类似,HEVC也采用Hybrid(混合)编码架构(见图1-17),但加入了许多新的工具集。此外,该标准也拓展到360度视频、3D视频等。

虽然HEVC的标准已经开发完成数年并且相比H.264有很大的压缩效率优势,但并没有得到很好的普及,究其原因是专利费的问题未能很好地解决。另一方面,由于HEVC推广步履维艰,与之竞争的编码标准格式近年吸引了大量关注,除YouTube外,Netflix等很多其他公司也大量采用VP9格式编码视频,以及持续关注号称完全开源和免费的AV1。

(8)AAC
德国的Fraunhofer-Gesellschaft协会下设80多个研究所,曾发明MP3等格式,为了比MP3得到更好的压缩性能,研究所和AT&T、杜比公司、索尼和诺基亚一起,设计了AAC格式。在后续章节中,我们会对AAC格式进行详细的介绍。因为AAC的优异特征,早先在MPEG2中就被标准化,见于ISO/IEC 13818-7,在加入SBR和PS技术后,又被作为MPEG4标准的一部分,称为MPEG-4AAC,以ISO/IEC14496-3为人所知。

1.3.3 独树一帜

(1)WEBM、VP9、OGG、Vorbis
WEBM项目受Google资助,采用Matroska格式为基础进行封装,内部采用On2Technologies开发的VP8和后续版本VP9视频编码器以及Vorbis、Opus音频编码器。On2公司曾开发颇为流行的VP系列编码器,尤以VP6知名,被Flash 8采用作为视频编码格式,后为Google收购。

2010年,在Google I/O上,VP8被以BSD License授权开源并允许所有人免费使用,Google从MPEG-LA取得了VP8可能受影响的专利,再次授权给VP8的使用者,解除使用者的后顾之忧。VP9作为VP8的后续版本,被Google期望与HEVC竞争。以WEBM格式、VP9、Vorbis为核心,Google的野心在于统一HTML5的视频编解码支持,Chrome、Mozilla都在浏览器内嵌支持VP9。

与VP8/VP9相伴,Vorbis是一种有损音频编码格式,由Xiph.Org基金会领导开发,通常以Ogg作为容器格式,所以也常被称作OGG音频,同时Vorbis可以被封装于Matroska格式中,也可用于作为Matroska子集的WebM。

(2)APE
无损音频编码格式APE,又称作Monkey’s Audio,与前面介绍的MP3、AC3/EAC3、AAC、Vorbis不同,这种编码格式可以保证解码出来的音频和原文件听起来完全一样。这是一种免费的编码格式,与之相似的还有FLAC等格式,在需要提供高品质音频下载服务时常被用到。

1.4 “幕后黑手”:标准组织

1.4.1 ISO/IEC MPEG

MPEG是Moving Picture Experts Group(动态图像专家组)的简称,组织成立于1988年,致力于开发视频、音频的编解码技术,MPEG-1、MPEG-2、MPEG-3、MPEG-4、MPEG-7、MPEG-21等标准均由其制定。MPEG工作组由ISO和IEC建立,下设需求、系统、视频、音频、3D、测试、交流等小组。在每次会议上,委员会将审查不同意见,将工作分配给下次会议的成员,MPEG所产生的ISO标准由5位数字表述(例如13818、14496),从小组内部的新工作建议开始,工作建议(NP、即新提案)先在小组级别,其次在整个委员会级别批准。

1.4.2 ITU-T VCEG

国际电信联盟电信标准化部门,即ITU Telecommunication StandardizationSector,缩写为ITU-T,是国际电信联盟下属的专门制定远程通信相关国际标准的组织,总部在瑞士日内瓦。
组织开发了JPEG、JPEG2000、H.261、H.262、H.263、H.264、H.265等一系列标准,极具影响。

第2章 音视频技术:框架

2.1 太祖长拳和岳家散手:DirectShow和MediaFoundation

随着软件开发的日渐复杂,框架逐渐成为常用的名词,通常它指实现了某种类型规范的软件,利于他人遵循使用。框架通常以组件化、规范化的形态出现,本身既可作为完整的软件,又可借此开发更加复杂的产品,供人使用。音视频领域以其专业性和复杂性,在很早就产生了多种框架,通常包含多达几百种的组件,开发者基于框架可以构造出无数不同类型的软件,帮助整个音视频开发组件化、标准化,令其容易传播,大大促进行业的进步。

据统计,曾真正服务或影响十亿级用户的音视频框架,只有DirectShow、MediaFoundation、Helix、FFMpeg、Android Media、AVFoundation等寥寥几种。DirectShow框架的流行,除Windows助力之外,其优异的模块化设计功不可没,即使以20年后的眼光评估,它也可算作设计精巧,容易上手,便于添加和分享新的功能组件的框架,国内大量的音视频开发启蒙都来自DirectShow。

2.1.3 Media Foundation

在Windows Vista之后,微软推出了新的Media Foundation框架(见图2-5)用于多媒体应用的开发,意图替代DirectShow,在每个版本的Windows中都增加了大量的新组件、新功能,如DRM支持,H.264、H.265编码支持等。MediaFoundation既支持与DirectShow相似的以Media Session为主的Pipeline模型(可类比于DirectShow中的Graph),又支持另一种简单的编程模型,仅含有Source Reader、Sink Writer以及Transcode API三部分,以简化使用难度。

2.2 全真武功:Helix

为同DirectShow分庭抗礼,支持自家不同产品线的开发,Real公司在20世纪90年代重金投入,打造出一个别有特色的多媒体框架Helix。使用Helix框架打造的包括许多业内耳熟能详的产品,如RealPlayer、Helix Server(即Real MediaServer)、Helix Producer、Helix Broadcaster等,虽然市场地位早已今非昔比,但直至笔者离开Real公司的2015年,基于Helix技术打造的部分产品仍保有一定的技术先进性。

2.2.1 产品系列

Helix Universal Server又称Helix Media Server,是以高性能、跨平台著称的流媒体服务器,主打直播和点播流的传输,开发了许多适合CDN服务的功能,早年在Akamai等公司的CDN网络中被广泛运用,并启发了许多现代高性能HTTP服务器的架构设计。

Helix Producer是基于Windows平台的专业转码工具,其免费版即Real Producer(见图2-8),很多国内的字幕组都将此工具作为日常使用,压缩出添加字幕、经过剪辑的RM或RMVB视频文件。Helix Producer与免费版相比较,除支持更多的格式外,主要增加了对专业视频采集卡的支持,各种滤镜、音视频编辑、台标嵌入等功能,以及与其他Helix产品的整合。

Helix Broadcaster是2013年RealNetworks推出的集多路编码和分发功能于一体的硬件设备(见图2-9),借助Helix框架在编码与流媒体服务的优异特性,HelixBroadcaster目标是打造成编码器领域的Wowza,提供当时业界最为丰富的功能集和超高的性价比,十分适合在线视频,可谓Helix框架最后的荣光。

2.2.3 特色技术

不同于DirectShow和后面要介绍的FFMpeg、GStreamer等框架,Helix框架的名气并非来自开发者,而是完全依赖几款重量级产品在产业历史上占据一席之地,支撑这些产品的,除了前文已有描述的RM、RMVB、RV、RA等文件与编码格式,尚有许多曾经走在时代前沿的特色技术,以下将择要进行介绍。

Sure Stream、RDT、RBS Real公司首先实践了Sure Stream(确定流)技术,即在一个文件或直播流内包含多种不同码率的音视频流,并在流媒体协议中探测播放器的带宽情况,选择不同的码率发送给播放器。RDT和RBS都是Real公司的私有协议,RDT还有公有的替代方案(即RTP和RTCP)

RSD(即Reduce Startup Delay,降低启动延迟)是一项针对RTSP或RTMP协议流媒体传输时优化启动时间的技术,因为播放器在开始播放前需要得到足够的缓冲数据,且播放需要从关键帧开始。由于在服务器中直播流存在一定长度的缓冲,当客户端发起请求时,服务端首先将保证从关键帧开始发送,而非简单地发送所持有的时间戳最早的包;其次,服务器会在发送初期按照3倍速率发送,以帮助播放器尽快填满缓冲区,开始播放。点播场景中的思路相似,服务端将在指定播放位置附近找到最近关键帧再行发送。

Server Side Playlist即服务端播放列表,这项技术主要用于广告插入,允许在服务端通过编辑播放列表的方式对点播和直播流插入广告,因为支持通过API动态加入和删除播放列表,广告插入的决定可以无限接近实时。

2.3 九阴真经:FFMpeg

FFMpeg(见图2-10)是由传奇程序员Fabrice Bellard[插图]发起的一个开源项目,“FF”的含义是“Fast Forward”,后项目由Michael Niedermayer主持维护,项目主要使用C语言

2.3.2 FFMpeg工具使用

ffprobe是用于检测文件或视频流的信息,并用尽量可读的方式打印出来的工具,当用户只想了解音视频文件的信息而不想真正播放或转码时,ffprobe就可以发挥作用

ffmpeg是用于转码的工具,即将一种格式的文件转成另外一种格式

ffserver提供了简易的流媒体服务器功能,仅需将打算发布的视频文件准备好,在配置文件中进行几行设置,再行启动ffserver,就可以供人访问。通过ffmpeg创建的音视频流可以被ffserver监听并发布出去,在Linux系统中,默认config文件的位置是/etc/ffserver.conf。

2.4 小无相功:Gstreamer

Gstreamer和DirectShow很相似,是基于Pipeline的流行多媒体框架,2005年发布的0.10版是Gstreamer早期的知名版本,随后逐渐受到硬件平台开发商的青睐,诺基亚、摩托罗拉、Intel、德州仪器等公司都纷纷采用。虽然Gstreamer是一个提供跨平台支持的多媒体框架,可以在Linux、Windows、macOS X、Android和iOS上运行,但应用最广的还是在Linux的一些发行版,以及嵌入式设备中。

GStreamer的代码完全开源,授权模式是LGPL,对开发者比较友好。Gstreamer的设计借鉴了DirectShow的思想,非常强调模块化,体系结构非常适合插件的开发,框架中所有的功能模块都可以被实现成组件,这一体系造就了大量的共享库,同时框架本身因为良好的抽象,也并不限定于必须处理音频和视频信息,可以用于构造非常复杂的应用程序。

2.5 圆月弯刀:VideoLAN

VideoLAN(见图2-16)是一个开源的、完整的视频流媒体和播放软件的解决方案,最初由Ecole Centrale Paris(巴黎中央理工学院)的学生建立,目的是在高带宽网络上传输MPEG视频。

在开发者中,VideoLAN更以VLC Media Player(VLC媒体播放器,界面见图2-17)为人所熟知(VLC是VideoLAN Client的缩写),现在VLC Media Player已经变成了一个全功能、跨平台的播放解决方案,其服务器方案VLS已停止单独开发,并入了VLC Player。

VLC的核心部分是libVLCcore,管理着VLC的线程、模块(各种编解码器,如Muxer/Demuxer)、模块的Layer、时钟、播放列表和其他所有低级控制,音视频和字幕的同步也由它负责。

x264(见图2-18)是VideoLAN旗下,按照GPL协议开源的H.264/AVC视频编码器,并接受商业授权给谈判付费的使用者。它以清晰的代码结构、较全面的标准支持和优异的性能著称,与标准的参考代码相比,主要舍弃了一些对编码性能贡献极小但计算复杂度又很高的特性。

2.6 倚天剑、屠龙刀:Android Media和AVFoundation

Android和iOS系统随着多年发展已然统治了移动端,与Windows提供MediaFoundation相似,Google和Apple也向其操作系统上的开发者提供了默认的多媒体框架,帮助他们开发播放器、滤镜、秀场直播等多种多媒体程序。与前面描述的各个框架不同,在Android与iOS系统上,如果意欲开发音视频应用,硬件在很大程度上限定了框架初始支持的格式,手机制造商或应用开发者往往通过内置一些软件版本的组件来扩展能力,例如FFMpeg

第3章 音视频技术:编码

世上没有免费的午餐,视频编解码技术将视频内容以减小空间占用但尽力保持观看质量的方式表达,代价则是非常复杂的编码算法和较长的计算时间。历经数十年发展,视频编解码的架构日趋稳定,压缩率和优化难度正在逐步接近瓶颈

3.1 编码技术概述

有损压缩则通过删除不必要或者不重要的内容来减少数据量。经过压缩的数据文件变小,在很多情况下能大幅减少存储和传输的占用,当然作为代价,需要计算资源来编码和解码,有时还要动用特殊硬件,如GPU或特制的芯片。

3.1.1 视频编码面临的问题

对原始图像或视频数据而言,分辨率可以代表清晰程度,越高的分辨率,越可能表现出越多的细节,但相应地需要的数据也就越多。屏幕的分辨率,也就是可以显示多少像素。早年间,VGA(640像素×480像素)作为IBM定义的显示标准为大多数显示器制造商所遵守,因此VGA就成了640像素×480像素的同义词。随后常见的分辨率还包括800像素×600像素(又被称作SVGA)、1024像素×768像素(XGA)等。视频中常用的720p、1080p、QHD、4K分别指1280像素×720像素、1920像素×1080像素、2560像素×1440像素、3840像素×2160像素分辨率。

以往,最常见屏幕宽与高的比例是4∶3,这来自于早期的电视标准,在近代宽屏兴起后,模仿电影的16∶9比例变得常见,视频的图像比例总是被设计成能满足尽可能多的预期受众,因此也以4∶3或16∶9的比例居多,但是就电脑显示器而言,16∶10也是常见的比例,因此1280像素×800像素、1440像素×900像素等分辨率也属常见。

除了分辨率不同,视频的颜色通道、帧率、场和传输内容也有很大的不同。首先,像素的颜色通道依据占据的比特数可以分为8Bit、10Bit、12Bit、20Bit等。其次,帧率[插图](Frame Rate,单位为帧/秒)也有24帧/秒、25帧/秒、30帧/秒、60帧/秒、120帧/秒等区别。

3.1.2 视频编码的思路

对于空间域上的压缩,其常用的技术和图片压缩技术十分相似,后续将详细介绍。而视频压缩独有的内容很大程度上集中在时间域上的压缩,也称帧间压缩,其主要思想是用一个或多个周围的帧来协助压缩当前帧,如果帧上没有移动的区域,就意味着冗余部分天然存在,数据只需编码或存储一次,即可在解码时重建多个帧。

现代的视频编码器里存在GOP(Group of Pictures)的概念,代表了一组连续的图像帧,通常而言,GOP中的第1帧编码为I帧,此外还有P帧和B帧的概念。I帧表示关键帧(Key Frame),其解码时不需要引用来自其他帧的信息即可完成(与图片编解码较为相像);P帧表示前向参考帧(Predictive Frame),体现了当前帧与前面参考帧的区别,需要依赖前面的I帧或P帧才可以解码;B帧通常又叫作双向参考帧(Bi-directional Interpolated Prediction Frame),记录了当前帧与前后帧的不同,需要依赖其前后两个方向的I帧或P帧才可以完成解码。

可想而知,解码时依赖其他帧的信息越多,说明当前帧的冗余越少,压缩率越高,一个简单的估算可以认为I帧、P帧、B帧的大小比例可达到9∶3∶1。

这里将引申出来DTS和PTS的概念,即Decode Timestamp(解码时间戳)和Presentation Timestamp(显示时间戳)。因为B帧需要参考后面的P帧才能正确解码,因此在解码的顺序上,后面的P帧将被先行解码并缓存,但在显示时,该B帧仍然应该先被显示出来。假设帧的原始序列为I、B1、B2、P1、B3、B4、P2……,这与显示的顺序完全一致,每一帧的PTS与实际视频录制的相对时间一致,而解码的顺序将是I、P1、B1、B2、P2、B3、B4……,DTS也将予以体现,以告知解码器每一帧应该被解码的时间。

历史上流行过许多种视频编解码算法,如MPEG-1Part 2(即用于VCD视频压缩的算法标准)、MPEG-2Part 2(即H.262,用于DVD的压缩算法标准)、RV(见前文编码格式介绍)、VC1(亦见前文编码格式介绍)、H.263(在视频会议领域曾广泛应用)、MPEG-4Part 2(即DivX、Xvid所用的格式)等。当前流行的编码器格式数量已大为减少,只有H.264/AVC、VP8/9、H.265/HEVC等寥寥几种,多家公司组成联盟,或在标准组织的框架下推动编解码技术的提升,期待格式可以得到最广泛的支持和运用已成为业界常态。

3.1.3 视频编码的发展

编码器的发展过程中,通常每一代编码器的设计目标是比之前的编码器压缩效率提升一倍。广播电视级SD(Standard Definition,即标清,448像素×336像素或512像素×288像素等分辨率)质量的视频,以往常使用MPEG2编码方式,其码率约等于3.75Mbit/s,高清视频则需要15Mbit/s以上。而作为领先两代的H.264,则可以在3~6Mbit/s的码率范围得到很好的1080p视频压缩质量,再进一步,VP9和HEVC在同等质量下码率还可以再节约30%~50%。

3.1.4 音频编码

音频编解码虽然格式众多,但与视频相比,缺乏脉络可循的技术换代,大致而论,MP3和AAC就可以代表不同的时期,虽然考虑到YouTube和其他少数几家公司,Vorbis/OGG格式也占据了不可忽视的份额。

3.2 从图像压缩开始

3.2.1 如何表征图像

RGB和YUV是图像常见的两类数字化表达。RGB是基于三原色原理,对红(Red)、绿(Green)、蓝(Blue)三个颜色通道叠加得到各式各样的颜色。当存储和处理图片文件时,RGB是最常见的方案,RGB24意味着用24Bit表示一个像素,RGB三个分量各用8Bit表示。按照B→G→R的顺序排列,RGB32在RGB24的基础上,对每个像素增加8Bit,用来表示Alpha通道值(即灰度或称透明度)。

YUV则是另外一种编码方式,其中Y表示明亮度,U表示色度,V表示浓度。它起源于黑白电视到彩色电视的过渡期,因为黑白电视仅有Y分量,如果彩色电视标准中采用UV表达色彩,则可以最大限度地和过往的格式兼容。

3.2.2 哪种格式更好

BMP是由微软开发的,常见的无损图片格式之一,内部使用的就是RGB格式,对24Bit或32Bit的RGB存储而言,数据区直接排列着每一个像素对应的RGB或RGBA的值(顺序实际为BGR和BGRA),但如同前文提到的,无损图片文件体积很大,一个800像素×600像素的24Bit图片需要占据约1.4MB的空间,800 600 3 /1024/1024 = 1.37M 并不是很适合在存储或传播的场合使用。PNG是另一种无损压缩的图片格式,由RFC2083标准描述,其中最广为人知的是它对Alpha通道的透明/半透明特性的支持,同样,因为体积较大,也仅适合在非常需要半透明效果的场合。

JPG/JPEG是值得重点关注的有损压缩的图片格式,它已流行多年,主要思路是舍弃人眼难以感知的颜色(高频)信息。JPEG格式里面支持的是YUV类型的图像,可以支持顺序式或渐进式(推荐使用,在下载时用户可以先看到模糊但完整的图片)编码,以及阶梯式编码。

SVG是一种适合应用于网页的矢量图形标准

针对有极致压缩优化需求的用户,还可以考虑WEBP和BPG等格式,WEBP衍生自视频编码格式VP8,由Google在BSD授权下开源,相比JPEG而言,同样质量的图片WEBP可节省25%~40%的大小。在Chrome、Opera浏览器和Android系统上,都内置了它的支持,但其他浏览器不能直接支持则是一大弊端,意味着服务端需要针对同一图像存储不同的格式。BPG格式是FFMpeg发起者Fabrice创建的一种图片格式,主要参考了H.265/HEVC的编码方法中的部分工具,它在某些情况下具有最好的压缩比。

3.3 一统江湖:H.264/AVC

H.264/AVC作为当前市场上最为流行的编解码标准,它的设计目标,不仅是在压缩效率上胜出市场上的其他编码器(例如它的实际压缩效率为MPEG2编码的2~3倍,也超出RV10至少50%),而且提供足够的灵活性,包括适应较高或较低的带宽、可应用于文件存储、在线视频服务、视频会议等。它实际定义了1~6.2一系列的Profile等级,每个Profile都有其不同的分辨率、码率、帧率等范围。

3.3.3 出色的实现:x264

在H.264的编码实践中,不论是入门使用、学习研究,还是商业项目,都可以考虑从最广泛应用的开源编码器x264开始。x264提供了UI工具和命令行工具,后者较为常用,它提供了多种参数供人使用,其中包含一些预先设置的参数集合,所有参数亦可以手动设置,覆盖预设参数集合中的一个或多个参数。由于x264已被集成到FFMpeg中,通过FFMpeg也可以灵活调用,但二者命令参数并不相同。

3.4 全面进化:HEVC/H.265

HEVC(High Efficiency Video Coding,高效率视频编码)又称作H.265,是更新一代以期望压缩效率高于H.264一倍为目标设计的编解码标准。HEVC于2012年2月完成Committee Draft,2013年1月完成Final Draft,基本达到设计目标,对在线视频应用来说,在低码率情况下,针对H.264尤其存在明显的质量优势。

3.5 更高、更快与更强:VP9、AV1与H.266

虽然VP8由于Google的推广背书受到了广泛的关注,但当时它的一些特性缺失(如缺乏B帧的支持、权重预测、没有8×8的变换、自适应量化、环路滤波的自适应强度以及主观质量优化等)让其相对于H.264处于明显的弱势,再加上对Google关于专利权声明的质疑,并无多少公司真正地使用VP8编码视频。然而数年过去,拜HEVC推广缓慢和专利费阴影所赐,经过Google多项重大提升的新编码器VP9,以及更多的人正在试图跟踪和评估的AV1,被许多公司当作值得认真考虑的选项。

3.5.1 另辟蹊径:VP9

VP9的开发肇始于2011年,在2013年被集成到Chrome浏览器中,相比VP8有着巨大的提升
VP9使用与HEVC相似的架构,并采用一些独特的技术使得二者在压缩效率上各有千秋,利用libvpx与libeve(前者系开源VP9编码器、后者系商业VP9编码器)编码均比x265在高分辨率情况下有一定优势,而远远超过H.264的编码效率。

3.5.2 最强编码:AV1

AOM即开放媒体联盟(Alliance for Open Media),由包括Amazon、Cisco、Google、Intel、Microsoft、Mozilla、Netflix在内的多家公司组建,当前又加入了Adobe、Broadcom、Hulu、NVIDIA、Polycom等多家公司,目标是提出较HEVC更先进的编码器并完全免费、避开专利限制。AOM当前的主要工作即是开发AV1编码器,已于2018年初正式发布,发布方式是直接以接近商业应用水平的代码与文档一起,置于BSD协议之下。

虽然AV1有很多好的特性,但到其广泛应用还尚有距离,主要的拦路虎一是播放设备的支持,二是编码速度较慢,按照以往的经验,至少还要两年才能让其进入实用的阶段。但另一方面,作为完全免费并有多家大公司背书的选项,AV1即使尚未实用,也已经为一些公司带来很大收益,例如HEVC的专利费在AV1的压力下大幅度下降,甚至不向流媒体分发的公司收费,对使用者而言是一项很大的节约。

3.7 难寻敌手:AAC/HE-AAC

作为音频编码格式的代表AAC,前文已有简略介绍,当前AAC流行于在线视频、广播电视和音视频通话等多个领域,又以MPEG-4标准的Part3即音频部分为人所熟悉。相比以往大为流行的MP3,AAC于编码流程上引入了多项新的技术,在压缩率、音质、解码效率、音轨与采样率支持等方向上全面超出。

3.7.2 多样化的封装

不同于视频编码器领域的激烈竞争,AAC由于其优异的设计,其生命周期要大幅长于视频编码器,在MPEG-2和MPEG-4中都被列入标准。编码器所生成的基本格式称作EP,在存储和网络传输中为便于使用

3.7.3 竞争对手

虽然AAC和许多其他音频格式均支持多声道,但针对多声道的播放,更为流行的音频格式是杜比的环绕立体声AC3或EAC3。这类格式得到了大量包括机顶盒、智能电视机、投影机、功放在内的设备支持,更重要的是得到好莱坞的支持,许多电影和电视节目的数据母带都采用它们,在广播电视领域,许多频道也在TS流内提供AC3或EAC3的声道,构成一个小的生态系统。

第4章 音视频技术:流媒体

今天的在线视频令人习以为常,然而从本地文件播放过渡到互联网服务,其中跨越了巨大的鸿沟,这一切都仰仗于互联网基础设施和流媒体分发技术的成熟。流媒体分发技术的具现是一系列的标准协议,与基础设施的演进相互关联、相互促进。本章将着重梳理不同的流媒体协议,其历史渊源和适用性,以及对工程分发所需的支持技术进行介绍。

4.1 流媒体技术综述

(3)服务器
当确定音视频格式和流媒体协议后,就轮到流媒体服务器粉墨登场,作为视频分发的主体,服务器应达到快速响应、高并发、高吞吐量和高可靠性。前面多次提到,视频文件的大小,促使人们研究编码技术和流媒体技术的关键,可以认为,整个视频技术,需要解决的核心问题是I/O问题。

4.2 不停歇的列车:MPEG2-TS

MPEG2-TS广泛应用于广播电视领域,也被苹果的HLS协议采用为其视频文件格式,其设计初衷即是视频流可以从任意片段开始解码。

4.2.1 MPEG-TS协议

TS流可视为由一系列188字节的包组成(在一些扩展中可能有不同长度)的“列车”,包头固定为4字节,以0x47作为同步码起始,其中的关键信息是PID。TS码流的基础是ES流即Elementary Stream,包含视频、音频或数据的连续码流,在此基础上,拆分成不同大小的数据包并加上包头,就形成了PES流。TS流由对一个或多个PES码流进行再封装得到,也即一个TS流可以包含多个PES流,一个音频PES包需要小于或等于64KB,视频PES包即是视频的一帧,由于TS包的负载大小仅为184字节,一个PES包需要被分成多个TS包进行传输,如有空余负载,则以固定值填充。

a36fbb773d4f70c9e33426dbee535d20.png

4.3 双向多车道:RTSP协议

RTSP(Real Time Streaming Protocol)是早期常用的流媒体协议,它用来建立客户端与服务器之间的会话,客户端发布播放暂停等命令。

4.3.1 RTSP协议

RTSP通常与RTP和RTCP协议共同使用,其中RTSP是服务端与客户端间的双向协议,它不负责传输音视频数据,而是用来控制多个音视频流。

RTSP通过不同的命令构建完整的控制会话,同时依赖RTP和RTCP或其他协议(例如在广播电视领域,有些方案采用TS作音视频传输)传输音视频本身的数据,一次典型的播放过程将在客户端和服务器间建立5个不同的Session:一路RTSP的Session、两路RTP的Session(音频和视频各一)以及两路RTCP Session(分别对应两路RTP Session),占用5个不同的端口(RTSP协议的默认端口是554,RTP及RTCP的端口由SETUP命令指定)。

RTSP协议支持重定向,即将播放会话重定向,让其他服务器提供服务。协议也可选择不同的传输通道,例如基于TCP、UDP以及组播UDP传输RTP协议。

4.3.2 RTP、RTCP与SDP

RTP是Real-time Transport Protocol的简称,定义于RFC1889标准中,初始被设计来单独使用传输音视频数据,后常与RTSP、H.323[插图]、SIP[插图]、WebRTC[插图]等协议配合使用。RTP协议将不同编码和封装格式的音视频数据进行再封装,加上RTP头(见图4-12)形成RTP包,再行发送,RTP包头内的重要信息包括序列号、时间戳、负载格式等。RTP协议提供抖动补偿和数据无序到达的检测机制,对实时多媒体传输,及时送达是首要目标,为此可以忍受部分丢包,少量丢包可以在客户端通过某些方法进行掩盖,不损害或少损害用户体验。

RTCP即RTP Control Protocol,亦由RFC1889定义,协议本身并不发送数据,而是收集客户端的统计信息,包括传输字节数、传输分组数、丢失分组数、网络延迟、Jitter(抖动)等,服务器可籍此改变码率或调节数据发送速度。

另一项与RTSP配合使用的协议是SDP,由RFC 2327规定,即Session DescriptionProtocol(会话描述协议),后重新发布为RFC 4566,用于和RTSP以及SIP等协议协同工作。

SDP同样基于文本,前述RTSP协议中DESCRIBE命令的回复即是SDP格式,SDP的格式异常简单,由多个<类型>=<值>的字符串组成,用于描述会话信息,也用于描述音视频的类型和格式,所需要的带宽、时间范围甚至邮件地址、编码参数等。例如,当传输AAC音频时,假如编码参数保持不变,就可以通过SDP会话传输StreamMuxConfig(AudioSpecificConfig)信息,同时RTP流只需承载audioMuxElements。

允许双向交换信息,使用多达5个会话交换数据的RTSP方式流媒体传输,很像是在双向多车道的马路上奔驰,无疑很大程度上解决了交通的问题,但“成也萧何,败也萧何”,多车道对资源的占用或许就是被后来的RTMP等协议挤占的根源。

4.4 高速铁路:RTMP协议

RTMP(Real-Time Messaging Protocol,即实时消息传输协议)是Adobe公司的专有协议,最初由Macromedia开发,属于Flash的一部分,后被Adobe收购后进行了扩展,该协议虽然应用广泛,但都基于Adobe公开而不完整的规范,Adobe在其上尚有许多私有定义,除非通过逆向工程进行解析,否则无法兼容使用。Adobe公开的部分协议内容可见Adobe网站。

4.4.1 RTMP协议

RTMP是基于TCP的可靠传输层协议,仅需一个会话即可相互通信,与RTSP协议相比,如同由轨道支撑的高速铁路,虽然形式略重,但效率高、速度快。

协议的主要概念是将音视频及其他数据封装为RTMP Message发送,而在实际传输时会进一步将Message划分为带有Message ID的Chunk。每个Chunk可以携带一个Message(见图4-13),但更多情况下,一个Message将由多个Chunk承载,直到客户端接收后将其还原。Chunk Stream是基于RTMP Chunk的逻辑抽象,客户端将据此区分不同类型的数据并组织接收以及还原。

RTMP协议支持Push和Pull两种模式,Pull即是普遍的客户端根据URL进行播放的方式,而Push基于RTMP的视频直播,其握手顺序和createStream步骤类似,由客户端使用Publish命令而非Play命令,发起自客户端到服务端的推送。

4.4.2 RTMP的应用

除Adobe自家的Flash Media Server以外,尚有Red5[插图]、SRS[插图]等开源RTMP服务器,或在Nginx上基于RTMP插件搭建的流媒体服务器等方案供在线视频服务商选择使用,大部分商用流媒体服务器也支持RTMP协议。同时在客户端,亦有JWPlayer[插图]、FlowPlayer[插图]等第三方提供的基于网页,对Flash支持出色的播放器,供使用者选择集成。中国国内的在线视频网站曾长期使用RTMP协议和Flash技术构建流媒体技术栈,在其上也进行了各式各样的定制开发。

RTMP协议在进行视频服务时,对动态码率切换广告插入、播放列表、直播频道快速切换等较为无力,故而在许多解决方案中,被设计以通过SMILSMIL格式是一种描述多媒体集成的格式,常用于和RTMP协议一道构建流媒体服务,但应用范围远不限于此。

4.5 快递物流:HLS、HDS与Smooth Streaming协议

除去RTSP、RTMP等基于会话的流媒体协议外,许多公司还设计了基于HTTP的协议,其中得到广泛应用的有HLS(HTTP Live Streaming)协议、HDS(HTTPDynamic Streaming)协议和Smooth Streaming(又称HSS)协议等。

4.5.1 HLS协议

HLS协议随苹果手机的推出而流行,不仅在苹果的手机、平板、Safari浏览器上成为首选的流媒体协议,许多视频网站也采用HLS及各种自定义的变种协议进行视频传输。协议的原理是将点播所需的多媒体文件或直播的视频流,切分成许多小块的文件,让客户端基于HTTP进行下载,当播放时,客户端需下载包含metadata信息的M3U8文件(也称作索引文件、Playlist或Manifest文件),根据M3U8文件的内容,同时依据网络条件选择不同码率的内容进行播放。M3U8文件是文本文件,后缀名常为.m3u或.m3u8,早先为描述MP3音乐的目的设计,其中M3U8即Unicode版本的M3U,在被苹果选取描述HLS协议的索引文件后,逐渐成为M3U8文件最大的用途。

HLS协议的一大特点在于,将以往RTSP、RTMP等协议中实现复杂的多码率、多音轨的音视频流变得容易,并可以明晰地表达、理解和优化,在协议中规定需要传递给客户端的信息可以由Master和Alternative两种M3U8来表达。在此设计中,客户端承担起了码率控制和选择的主要职责,每个播放器可以根据自己的网速选择合适的码率播放,并在网络环境波动或某些文件下载失败的情况下切换到其他码率,保持流畅播放,服务端则对缓存和CDN友好,毋需针对不同用户予以不同处理。

近年来,由于MPEG-DASH带来的压力(后续将详细介绍),苹果开始在HLS中支持fMP4,例如对HEVC以及HDR编码的音视频必须封装为fMP4格式才能被苹果设备播放。

4.5.2 HDS与Smooth Streaming

与HLS同一时期制定的,具备相似特性(基于HTTP、支持多码率、音视频文件切片)的流媒体协议另有Adobe推出的HDS(HTTP Dynamic Streaming)和微软推出的Smooth Streaming,它们与MPEG-DASH一道,被称作Adaptive BitrateStreaming技术(码率自适应的流媒体技术)。HDS由Adobe自己的Flash MediaServer支持,其文件格式为FLV、F4V和MP4,索引文件格式为F4M,支持直播和时移电视。

4.6 菜鸟网络:MPEG-DASH

MPEG-DASH是由MPEG牵头开发的基于HTTP的自适应码率流媒体技术,于2011年11月形成国际标准,其标准文档为ISO/IEC 23009-1,发布自2012年4月,目标是统一不同公司的自适应码率技术。微软、高通、Google、Akamai等公司出力甚多,并获得YouTube、Hulu、Netflix等在线视频巨头的倾力支持,在短短几年间已经俨然取代RTMP,成为应用最广的流媒体协议。

基于HTTP的流媒体协议流行,从环境上考量,主要的原因是HTTP协议对防火墙友好,又天然适合CDN以缓存的方式分发,此外苹果的强势地位加快了基于HTTP的流媒体协议进入开发者视野的速度。

4.6.1 MPEG-DASH协议

MPEG-DASH与前面介绍的HLS、HDS、Smooth Streaming的设计理念相近(见图4-18),将音视频文件或直播流分割成一系列可下载播放的文件切片,使用MPD文件描述切片信息。MPD内有时间戳、编码、分辨率、码率等信息,对音视频内容的组织方式分为SegmentBase、SegmentTemplate、SegmentList和SegmentTimeline等类型,在客户端对MPD文件解析后,再行下载所需的文件切片,交由播放器组装并播放。

DASH协议原则上可以支持任何编码格式,作为指导意见,推荐使用与HLS协议兼容的TS文件或ISO-BMFF的扩展作为多媒体文件格式(即Fragmented MP4),后者的文件后缀多见.mp4、.m4v、.m4a或.m4s。

4.6.2 协议应用

流媒体协议的流行常是技术权衡、公司角力、行业趋势等多方碰撞的结果,如同Flash的流行刺激了RTMP流行,MPEG-DASH被接纳成为HTML5标准的一部分对其流行也起到重要的作用。最重要的一些现代浏览器(如Chrome、Edge、Firefox、Safari等)均对W3C标准定义的MSE(Media Source Extension,媒体源拓展,见图4-20)和EME(Encrypted MediaExtensions,加密媒体扩展,见图4-21)进行了支持,将以往由插件提供的功能收归浏览器,运用Javascript开发的网页播放器只需下载MPD文件并解析,再将音视频文件送给浏览器,就能很容易地播放。

4.7 物流中心:流媒体服务器

4.7.1 流媒体服务器的功能与挑战

通常流媒体服务器所面对的功能需求囊括点播和直播两类,点播服务需要将硬盘或其他存储设备上的音视频文件转化成流媒体传输协议规定的一系列包(Packet),发送给不同的客户端。直播服务则需要先将基于IP网络,由流媒体协议封装的音视频流导入服务器,再通过服务器转化成不同设备可以接收的流媒体封装,发送给各个客户端。

(1)面对的客户
服务器面对的客户端多种多样,电脑上有Chrome、Edge、IE、Firefox、Opera、Safari等浏览器,也有VLC、QQ影音、暴风影音等播放器,其他设备从旧式基于嵌入式Linux或Symbian、黑莓系统的智能手机,到现代的苹果或Android设备,从Roku、FireTV、小米盒子类型的机顶盒到XBox、Play Station、Nintendo系列游戏机,从Chromecast类的无线投影设备到Oculus、Vive、HoloLens等虚拟现实、增强现实设备,各个设备上的音视频应用均是目标服务对象。

(2)协议支持
不论点播,还是直播,由于不同的流媒体协议规定了不同的传输格式,也即对相同的音视频编码格式基础上采取了不同的封装,服务器主要的工作是将文件转化为流媒体协议,流媒体协议转化为文件,一种流媒体协议转化为另一种流媒体协议,转化时根据文件格式和流媒体协议格式进行解包和封包(英文是Packetize和De-packetzie)。以H.264和AAC格式的音视频内容,在传输时需要封装为NAL格式和ADTS、LOAS格式,再封装到不同的协议包中,例如RTP包、TS包等,以此为单位发送或接收。

(3)服务角色
流媒体服务器常见的应用位置是视频网站的源站,以及CDN服务中包括源站(Origin)、中间站(Proxy)、边缘站(Edge)在内的各级节点,构成视频分发的核心。

流媒体服务器根据所部署的位置,可以被定义成不同角色,如Publisher和Subscriber,Publisher即源站或上游站,Subscriber即下游站或边缘站,则对于直播流服务器而言,我们面对的主要问题是如何可靠和低延时地将流分发到边缘节点,对点播服务,请求边缘节点上不存在的视频会导致回源请求,而访问过的文件片段将被缓存在边缘节点以供下次访问,服务器的特殊挑战是如何高效地对缓存进行使用和管理。

(4)应用特点与优化
对HTTP服务器而言,需要缓存的文件片段是基于Range请求获得的,若举例而言,则可以假设是某一个文件的从3000到7000字节,但于音视频文件则略有不同,由于视频关键帧概念的存在,获取或存储不完整的GOP数据并无意义,因此不论返回用户请求的内容还是在本地缓存音视频片段,都以贴近所请位置的GOP为单位较有效率,此时缓存中应有音视频片段对应的时间戳信息以便索引。

同理,针对直播流,因为用户可以从任意时间开始观看,为节约带宽并加快播放启动的速度,服务器应从自身持有的音视频流的队列中找到关键帧,由该处起始服务,避免发送不完整的GOP数据。当用户在不同频道间切换时,如果音视频格式相同,流媒体服务器可以使用当前与用户之间的连接,从新频道的关键帧开始发送等方法(见图4-25),达到最佳的用户体验。

通常情况下,因为视频流的传输受到带宽、网络传输稳定性、客户端等待渲染等多方面限制,从编码器、源站服务器、代理服务器到边缘站服务器,以及播放器本身,每一个环节都会保持一份缓存,这有助于整个传输过程的流畅,但代价即是播放器的播放存在延迟,若在直播情况下,还将导致看到的节目系数秒乃至数十秒之前所发生的内容。服务器内部通常维护的Packet队列,可根据不同场景调整大小,在直播特有的追求低延时的场景下,该队列甚至可以被取消,即服务器收到任一Packet都会立刻处理转发。

4.8 物流服务:CDN

CDN是Content Distribution Network的缩写,是利用多个分别部署的数据中心、机房、服务器,在网站和用户之间插入一层网络架构,选取最靠近或服务质量最佳的服务器为每位用户提供服务。CDN可以有效地解决网站容量不足、互联网拥塞、降低主干网流量占用、提高用户响应速度和下载速度等问题。

第5章 音视频技术:播放

5.1 视频领域的大保镖:DRM

DRM(Digital Rights Management,数字版权保护)是用于保护视频内容的一系列访问控制技术集合,用于控制视频和设备的使用过程,包括对视频的使用、播放、拷贝、修改等。

5.1.1 加密技术

令DRM技术成为现实的基础是加密技术,原理在于将明文信息改换为难以读取的密文信息,只有具备解密方法的对象经由特定过程,才能将密文还原为正常可读的内容。加密算法分为对称加密和非对称加密两类,对称加密将信息使用一个密钥进行加密,解密时只需使用同样的密钥,按同样的算法进行解密,非对称加密算法则在加密和解密环节使用不同的密钥(见图5-1)。常见的对称加密算法有DES、AES、IDEA等,非对称加密算法有RSA、ElGamal、ECC等。

本原创文章未经允许不得转载 | 当前页面:慢慢 » <在线视频技术精要> 摘录

评论