音视频系列2：基本知识

1. 存储格式

1.1 WAV、WMV、WMA、ASF、MMS、AVI：微软全家桶

微软的东西，windows用户经常能见到。
首先是wav音频文件。WAV是微软开发的一种声音文件格式，它实际是采用RIFF文件规范存储的，WAV是文件的扩展名，内中音频的格式通常是PCM，也可以存储一些压缩过的数据；然后是名为WMA的音频编码格式，能够以较MP3少1/3～1/2的码率存储相似音质的音频，通常后缀名为“.wma”。
wmv/asf是一系列由微软开发的视频编码格式和文件格式。其中WMV version 9因为被许多地方选用而以VC-1编码格式之名为人熟知，微软为此专门开发了一种名为ASF的文件格式来存储，但后缀名既可能为“.asf”，也可能为“.wmv”。
nms流媒体协议：微软在同时代还曾开发过名为MMS的流媒体协议，基于UDP或TCP进行传输，后升级为MS-WMSP协议（又称WMT，即Windows Media HTTP Streaming Protocol），可以使用HTTP传输。
AVI全称Audio Video Interleaved，是微软在很早便推出的多媒体文件格式，但因其良好的适应性，仍然被广泛使用。AVI可以支持非常广泛的音视频编码格式，包括较新的H.264、HE-AAC等。AVI由RIFF格式衍生，它的文件结构分为头部、主题和索引三部分，描述信息通常放在INFO chunk里，视频和音频数据在主体中依照时间信息交互存放，从存在尾部的索引可以任意跳到视频流的中段。因为索引的尾部设计，AVI不太适用于流媒体传输的场景，更详细的文件格式描述可以参考MSDN。
RIFF系Resource Interchange File Format的缩写，每个WAVE文件的初始四个字节即为’RIFF’，并由多个Chunk组成，其格式大致如下：

1.2 MP3：音乐的代名词

德国组织开发，传播广泛的音频格式，流行到成为歌曲和播放硬件的代名词了。
以WAV为代表的音频文件因为未经压缩，所以较少用来存储较长的声音内容，在20世纪末，大量音频文件使用MP3格式进行存储，下载和交换，提供较好的音质和压缩比率，甚至催生了以此为名的硬件设备，虽然市场上早有压缩率更好的格式诞生，但MP3格式一直流行到现在。MP3的准确名称应为MPEG-1或MPEG-2Audio Layer 3，它的发明和标准化是由德国的研究组织Fraunhofer-Gesellschaft完成的，而它的普及，则对整个世界的音乐生态影响深远。
MP3实质是对PCM数据中涉及的人类听觉不重要的部分进行舍弃，从而压缩得到较小的文件，它提供多种不同的bitrate（每秒所需数据）的选择，常见速率有128kbit/s、192kbit/s、320kbit/s等。

1.3 RM、RMVB、RV、RA：Real公司视频套餐

Real公司开发，传播广泛的视频格式，非常像流媒体，曾经很火，现在已经很少人用了。
RM即RealMedia，是RealNetworks公司创建的专用多媒体容器格式，文件扩展名多用“.rm”，通常用于RealVideo和RealAudio的结合，一般是CBR（固定码率）编码，RMVB则是RM的换代格式，支持可变码率。RM格式的主要特征在于不需要下载完整文件即可播出，并可以根据不同的网络传输速率制定不同的压缩比率，可见它一开始就定位在流媒体应用方面。
每个RM文件内部，是由一系列的Chunk组成，每一个Chunk的格式如下：

RM文件支持的Chunk类型包括.RMF（文件头）、PROP（文件属性）、MDPR（流属性）、CONT（内容描述）、DATA和INDX（文件索引），更多文件格式信息可见参考文章。
RV是RealNetworks独有的视频编码格式，由于采用了诸多领先的技术，在低码率情况下有非常出色的压缩比，相对应的，RA格式是公司专有的音频编码格式。普通RM文件中使用RV8.0版本，而RMVB文件中则通常是RV9.0或10.0版本，实际RM与RMVB格式可以支持另外一些编码器版本，但并不常见。

1.4 MPG：国标

国际标准，你看到的MPG .MPEG .MPE .DAT .VOB .ASF .3GP .MP4文件很多都是mpg格式。
mpg英文全称为Moving Picture Experts Group，即运动图像专家组格式，该专家组建于1988年，专门负责为CD建立视频和音频标准，目前有MPEG-1、MPEG-2、MPEG-4四个标准。
MPG文件内含两种文件格式，即PS（Program Stream，节目流）和TS（Transport Stream，传输流），分别用于不同的场合，根据格式不同，后缀名也可能是“m2p”“.ps”或“.ts”。
PS格式来自于标准MPEG-1Part1（ISO/IEC 11172-1）和MPEG-2Part1（ISO/IEC 13818-1/ITU-T H.222.0），PS格式由一个或多个PES组成（Packetized Elementary Streams，封装的基本流），其中每个流具有一个时间基准，用来在磁盘上进行存储。该格式里面还可以包含多种格式。
TS格式则更适合网络传播，同样来自ISO/IEC 13818-1标准。在逻辑上，一个TS文件（或传输流）包含一组SubStream（即PES），可以是视频、音频、MJPEG或JPEG2000的图片、字幕或EPG。每个流都被分解组装到188字节大小的包中，由于每个包都较小，可以容易部分地传输，各个流之间可以交错排布。每个TS包都包含有一个4字节大小的包头，其中包含同步字节和PID（Packet Identifier，包标识）等信息，每个PID值都描述了TS中的一个流，例如，当PID为0×0时，表示当前流为PAT，描述了整个TS包含的信息。而PAT流中另行描述了PMT流的PID，据此可以找到其他各个音视频流的信息。PAT和PMT可以被统称作PSI（即Program Specific Information，节目专用信息，实际这个概念下还包含CAT和NIT两种流），也是解析TS文件的关键。更详细的信息可参考标准文档或维基百科。

1.5 MOV、MP4(mpa/m4v)：苹果全家桶

MOV又被称作QuickTime File Format，可以包含一个或多个Track，每个Track存储：视频、音频或字幕中的一种类型的数据，每个Track又由一个层次分明的Object结构组成（每个Object又叫Atom）。一个Atom可以包含其他Atom，也可以包含多媒体数据，但不能兼得。
MP4文件几乎完全基于QuickTime文件格式，它由标准ISO/IEC 14496-12规定，并且添加了extension，形成MPEG-4Part14。MP4文件还常有另外一些文件名后缀，如“.mpa”，“.m4v”等。详细的文件格式定义可参见标准文档。
MP4文件用于下载播放时，moov对象应写在mdat对象前面，以便在访问数据前收到所有的metadata信息。用于流媒体播放时，则文件内应有特殊的Track（Hint Track），每条Hint Track将与一条多媒体Track连接，用于描述流式传输所需的信息。

1.6 3GP：3G时代的手机视频

3GP常被称作3GPP文件，是由3GPP组织定义的文件格式，设计目的是用于3G移动网络中，其定义和MP4非常像，也是基于MPEG-4Part12发展出来的。另外又有3G2或称作3GPP2的文件格式，其和3GP文件的区别是，一个用于GSM网络，另一个用于CDMA网络。

1.7 FLV、F4V：adobe公司，流媒体的推广人

flv是flash的缩写，老一辈熟悉的adobe flash player就是官方播放器。flv是一种适用于流媒体传输的视频格式，内部初始基于Sorenson公司的编码算法，也支持H.263及VP6等格式。由于YouTube、Hulu、优酷、土豆等网站早期均大量使用Flash技术，FLV文件也变得非常流行。与之配合，FLV文件的传输多使用RTMP协议，Adobe还提供免费的Flash Media Encoder（Flash媒体编码器）帮助生成FLV格式的文件。
在Flash Player 9的Update3中，Adobe推出了F4V格式，主要为支持H.264和AAC编码，文件格式完全基于ISO Base Media File Format（即ISO/IEC 14496-12）的标准，与MP4、3GP文件格式等高度相似。

1.8 MKV、MKA、MKS：开源、好用，未来主宰？

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

1.9 AC3：装逼音乐格式

Dolby Digital格式，又称作AC3，是Dolby（杜比）公司开发的一系列有损或无损音频格式中的一种，其规格标准的名称为ATSC A/52，俗称5.1，因为音频内容包含5个不同的基础声道［即右前（RF）、中（C）、左前（LF）、右后（RR）、左后（LR）］以及一个低频声道。与之相关的还有Dolby Digital EX（杜比数字扩展）、Dolby Digital Live（杜比数字直播）等，其中Dolby Digital Plus应用较为广泛，支持多达14声道，别名为EAC3。在广播电视领域中，AC3或EAC3常常用作原始文件的格式，也可通过TS流形式传输，常见的码率有384kbit/s，448kbit/s等。关于AC3和EAC3的详细描述，可参考ATSC的标准文档。
近年来，杜比又开发了全景声技术（Dolby Atmos），继续其在高质量影音播放效果方面的布局，但它和AC3/EAC3技术不能兼容。

1.10 AAC：还是那家德国公司

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

1.11 WEBM、OGG：谷歌全家桶

webm是一种存储格式。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。
ogg音频一般使用Vorbis编码格式。这是一种有损音频编码格式，由Xiph.Org基金会领导开发。Vorbis可以被封装于Matroska格式中，也可用于作为Matroska子集的WebM。

1.12 APE、FLAC：免费无损音频格式，发烧友必备

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

2. 编解码技术

2.1 H.263：旧时代的技术

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

2.2 H.264：物美价廉

标准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万美元。
编码格式详细描述可见ISO标准文档。

2.3 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的专利，要求收费，包括MPEG-LA、HEVC-Advance专利池等，Velos Media和Technicolor公司等也都有独立发起的专利池或专利收取意向，且在费用需求上非常巨大，让硬件和服务商望而却步。
另一方面，由于HEVC推广步履维艰，与之竞争的编码标准格式近年吸引了大量关注，除YouTube外，Netflix等很多其他公司也大量采用VP9格式编码视频，以及持续关注号称完全开源和免费的AV1。

2.5 VP9、Vorbis：谷歌系列

上面介绍过了。

2.6 其他

在工业界几十年的发展过程中，曾经广泛使用的文件格式和编码技术远不止上述种类，还有如ALACDV、DivX、G.719、G.722、G.723、MOD、Sorenson、VOB等，国内一些标准（如AVS、AVS2等）也取得了一定的用户。但由于多媒体工业已经发展到一定的阶段，占优势的格式会形成马太效应，除通用播放器，编码器需要比较注意完整的格式支持以外，大多数在线服务仅需要选取少量可以跨平台支持的编码和文件格式。

3. 多媒体框架与软件

这是一场没有硝烟的战争。曾真正服务或影响十亿级用户的音视频框架，只有DirectShow、Media Foundation、Helix、FFMpeg、Android Media、AVFoundation等寥寥几种。

3.1 微软家：DirectShow和Media Foundation

DirectShow是最早的也是非常著名的音视频框架之一，简称DShow，由微软公司开发。它的早期名称为ActiveMovie，当时被视为对苹果公司QuickTime软件做出的回应。直到1998年，它被包含在DirectMedia SDK之内发布，并改名为DirectShow，之后随着Windows系统流行于世。
据统计，DirectShow框架的流行，除Windows助力之外，其优异的模块化设计功不可没，即使以20年后的眼光评估，它也可算作设计精巧，容易上手，便于添加和分享新的功能组件的框架，国内大量的音视频开发启蒙都来自DirectShow。DirectShow的设计理念是，开发者创建一个Graph（也可称Pipeline），将所有用到的组件（称作Filter）加入Graph当中，当应用运行时，Graph找到了注册的Filter并为之连接。Filter常用于对音视频流的某一步的处理，包括文件读取、渲染等。
当开发者接触DirectShow时，首先会关注到它的一个工具GraphEdit，这是一个用于建立和测试Graph的可视化工具。在GraphEdit中，可以加入所需的Filter（过滤器），将Input Pin（输入探针）和Output Pin（输出探针）连接起来，如果连接正常，就可以执行播放操作。下图描述了播放一个MP3文件时，在GraphEdit中看到的Graph结构，包括读取MP3文件、解封装、解码、默认声卡设备以及它们之间的连接。

DirectShow基于微软的COM技术（Component Object Model），以C++开发，但用户不必自己开发COM对象，只需要使用或继承框架提供的组件即可。默认提供的组件支持ASF、MPEG、AVI、MP3、WAV等多种文件格式或编解码格式。

在Windows Vista之后，微软推出了新的Media Foundation框架用于多媒体应用的开发，意图替代DirectShow，在每个版本的Windows中都增加了大量的新组件、新功能，如DRM支持，H.264、H.265编码支持等。Media Foundation既支持与DirectShow相似的以Media Session为主的Pipeline模型（可类比于DirectShow中的Graph），又支持另一种简单的编程模型，仅含有Source Reader、Sink Writer以及Transcode API三部分，以简化使用难度。如同其他现代框架，Media Foundation提供命令行工具MFTrace和可视化工具［如TopoEdit等］给开发者使用。

3.2 Real家：Helix

Real公司在20世纪90年代重金投入，打造出一个别有特色的多媒体框架Helix。使用Helix框架打造的包括许多业内耳熟能详的产品，如RealPlayer、Helix Server（即Real Media Server）、Helix Producer、Helix Broadcaster等。
稍有几年网龄的朋友应该都对RealPlayer并不陌生，作为早年大为流行的播放器，它初始以优良的播放质量闻名，后又不断添加各种功能，如应用内的转码工具、视频点播、广播电台、网络视频下载插件等。2013年，Real公司曾推出与RealPlayer整合的RealTimes功能，支持将用户的所有私人图片与视频进行云端存储并自动生成剪辑，希望切入社交领域，但未能成功，同时商业模式不明确，又没有深度学习加持的视频剪辑功能也很快被Google Photos等各家竞品轻松超过。
Helix Universal Server又称Helix Media Server，是以高性能、跨平台著称的流媒体服务器，主打直播和点播流的传输，开发了许多适合CDN服务的功能，早年在Akamai等公司的CDN网络中被广泛运用，并启发了许多现代高性能HTTP服务器的架构设计。
Helix Producer是基于Windows平台的专业转码工具，其免费版即Real Producer，很多国内的字幕组都将此工具作为日常使用，压缩出添加字幕、经过剪辑的RM或RMVB视频文件。
Helix Broadcaster是2013年RealNetworks推出的集多路编码和分发功能于一体的硬件设备，借助Helix框架在编码与流媒体服务的优异特性，Helix Broadcaster目标是打造成编码器领域的Wowza，提供当时业界最为丰富的功能集和超高的性价比，十分适合在线视频，可谓Helix框架最后的荣光。
Real公司首先实践了Sure Stream（确定流）技术，即在一个文件或直播流内包含多种不同码率的音视频流，并在流媒体协议中探测播放器的带宽情况，选择不同的码率发送给播放器。RDT和RBS都是Real公司的私有协议，RDT还有公有的替代方案（即RTP和RTCP），但由于RDT允许在一个流上同时传输音频和视频等不同信息，XAML是WPF所依赖的UI描述语言。
因而它有着比RTP/RTCP更好的性能。RBS则完全用于在Real公司的产品之间发送直播流，它是基于UDP的轻量级协议，几乎没有冗余的信息。例如，解码器所需的参数信息在编码器、服务器和播放器之间均以二进制传递，除带宽节省外，还可以避免序列化和反序列化的时间，有着极高的性能。
RSD（即Reduce Startup Delay，降低启动延迟）是一项针对RTSP或RTMP协议流媒体传输时优化启动时间的技术，因为播放器在开始播放前需要得到足够的缓冲数据，且播放需要从关键帧开始。由于在服务器中直播流存在一定长度的缓冲，当客户端发起请求时，服务端首先将保证从关键帧开始发送，而非简单地发送所持有的时间戳最早的包；其次，服务器会在发送初期按照3倍速率发送，以帮助播放器尽快填满缓冲区，开始播放。点播场景中的思路相似，服务端将在指定播放位置附近找到最近关键帧再行发送。
另一项与之相关的技术称作Fast Channel Switching，即快速频道切换，当播放器意图切换点播节目或直播频道时，其与服务端之间建立的连接并不销毁重建，而是复用已存在的Session，服务端从新节目的关键帧开始加速发送，可以避免重建播放会话带来的屏幕中断，并达到最快的节目切换。
Live Low Latency译为直播低延迟，对于直播服务而言，一项重要的直播是它的时延。例如体育直播，人们不希望在地球彼端的球赛进球已经许久的情况下本地才看到对应的信号，早在2004年的纳斯卡赛车直播中，Real公司就已经在互联网上部署了端到端延时仅为4s的流媒体服务，而Live Low Latency技术则可以进一步压榨延时性能。
此外，Helix框架还曾提供服务端码率控制、码率切换、服务端播放列表（用于广告插入）、Cloaked RTSP（隐匿的RTSP，用于防火墙穿越）、HTTP连接统计等诸多特有功能

3.3 新起之秀：FFMpeg

FFMpeg是由传奇程序员Fabrice Bellard发起的一个开源项目，“FF”的含义是“Fast Forward”，后项目由Michael Niedermayer主持维护，项目主要使用C语言，其授权协议是LGPL，但其中部分代码的授权是GPL。由于数百名贡献者多年持续不断的努力，使当前FFMpeg项目拥有几乎全部常用的图像、视频、音频编解码和文件解析、封装库，以及流媒体协议支持。
与模块化、组件化设计的其他多媒体框架略有不同的是，FFMpeg更常见的使用方式是直接运行编译完全的命令行工具ffprobe、ffplay、ffmpeg、ffserver等，以及作为功能库整体，被包含到其他软件甚至多媒体框架中。
编译好的FFMpeg程序可从其官网进行下载安装，同时官方也提供源代码的github下载。对于开发者来说，不论是为了使用最新的代码、定制化功能还是选择特定的版本，自己编译源码再安装都是必由之路，因为在默认情况下，许多库虽然有源代码，却是没有被选择编译的，需要在第一步设置的时候打开对应选项，例如，假设想使用x264来作H.264编码，则第一步是保证在系统内存有相应的Library，在configure时选择–enable-libx264。更进一步，很多情况下，你还需要这些Library的开发包，如果想打开–enable-libmp3lame，需要安装libmp3lame-dev。
fprobe是用于检测文件或视频流的信息，并用尽量可读的方式打印出来的工具，当用户只想了解音视频文件的信息而不想真正播放或转码时，ffprobe就可以发挥作用。
ffmpeg是用于转码的工具，即将一种格式的文件转成另外一种格式，通过支持filter机制（和DirectShow的Filter概念颇有几分类似，但更多是一种虚拟概念）和搭建Filtergraph，不论使用命令行还是代码，都可以建立复杂的工作流。
ffserver提供了简易的流媒体服务器功能，仅需将打算发布的视频文件准备好，在配置文件中进行几行设置，再行启动ffserver，就可以供人访问。通过ffmpeg创建的音视频流可以被ffserver监听并发布出去。

3.4 老牌框架：Gstreamer

Gstreamer和DirectShow很相似，是基于Pipeline的流行多媒体框架，2005年发布的0.10版是Gstreamer早期的知名版本，随后逐渐受到硬件平台开发商的青睐，诺基亚、摩托罗拉、Intel、德州仪器等公司都纷纷采用。虽然Gstreamer是一个提供跨平台支持的多媒体框架，可以在Linux、Windows、macOS X、Android和iOS上运行，但应用最广的还是在Linux的一些发行版，以及嵌入式设备中。GStreamer的代码完全开源，授权模式是LGPL，对开发者比较友好。
Gstreamer的设计借鉴了DirectShow的思想，非常强调模块化，体系结构非常适合插件的开发，框架中所有的功能模块都可以被实现成组件，这一体系造就了大量的共享库，同时框架本身因为良好的抽象，也并不限定于必须处理音频和视频信息，可以用于构造非常复杂的应用程序。由于Gstreamer定位在通用的多媒体框架，因此很注意与其他软件和框架建立联系，例如，视觉框架OpenCV、OpenGL，多媒体框架FFMpeg等，允许简单地进行重用和互操作。同时考虑到开发者的实际需求，Gstreamer也允许人们方便地进行裁剪，仅仅选取符合自己需要的模块嵌入应用中。
streamer不同，它是高度模块化的管线驱动式的媒体框架，扩展性极强。理论上，不只是媒体流，gstreamer可以扩展为处理任何一种数据流。因此，架构上,gstreamer更强大，扩展性更强。ffmpeg的核心转码功能也可以作为gstreamer的插件扩展，可以认为gstreamer可以整合ffmpeg的功能，并大大超越ffmpeg所能做的范畴。
AI时代，gstreamer依托于不断更新丰富的各种AI插件,大有可为。一个典型的例子是英伟达公司基于gstreamer推出了业界首个视频分析系统框架:DeepStream.

3.5 开源好用：VideoLAN

VideoLAN是一个开源的、完整的视频流媒体和播放软件的解决方案，最初由Ecole Centrale Paris（巴黎中央理工学院）的学生建立，目的是在高带宽网络上传输MPEG视频。
在开发者中，VideoLAN更以VLC Media Player为人所熟知（VLC是VideoLAN Client的缩写），现在VLC Media Player已经变成了一个全功能、跨平台的播放解决方案，其服务器方案VLS已停止单独开发，并入了VLC Player。
VideoLAN基于GPL协议开源，因此轻易地决定在商业产品中基于其定制开发或许是一个不智的方案，但不妨碍VLC作为可靠的独立工具被广泛使用。此外，VLC允许被作为浏览器的Plugin安装并使用，这大大方便了许多需要在网页中完成多媒体功能的需求。
x264是VideoLAN旗下，按照GPL协议开源的H.264/AVC视频编码器，并接受商业授权给谈判付费的使用者。它以清晰的代码结构、较全面的标准支持和优异的性能著称，与标准的参考代码相比，主要舍弃了一些对编码性能贡献极小但计算复杂度又很高的特性。x264针对多种硬件平台都进行了汇编优化，既能按照命令行方式使用，也提供API，供多个多媒体框架（如FFMpeg和VideoLAN）引用。
初始，x264由Laurent Aimar建立，在2004年Loren Merritt接手项目，2005年的第二届MSU编码器大赛上，x264获得第二名，建立了最初的名气，到了2010年，x264在多个项目上均获得第一，并大幅领先其他参赛者，被认为是最好的H.264/AVC编码器，Dark Shikari（真名Jason Garrett-Glaser）加入x264的开发被很多人认为是它脱颖而出的重大因素。
x265是一个近年较新的项目，目标是实现一个高效率的H.265/HEVC编码器，同样按照GPL协议开源，它支持大部分x264的特性（重用了许多代码），与x264不同的是，它在最初由多家公司赞助开发，这些公司得以在产品中使用x265并不需要按GPL授权发布其特有代码。

3.6 移动端：Android Media和AVFoundation

Android和iOS系统随着多年发展已然统治了移动端，与Windows提供Media Foundation相似，Google和Apple也向其操作系统上的开发者提供了默认的多媒体框架，帮助他们开发播放器、滤镜、秀场直播等多种多媒体程序。
与前面描述的各个框架不同，在Android与iOS系统上，如果意欲开发音视频应用，硬件在很大程度上限定了框架初始支持的格式，手机制造商或应用开发者往往通过内置一些软件版本的组件来扩展能力，例如FFMpeg
在Android平台上，开发者接触的首先是一系列Media接口，包括MediaPlayer、MediaCodec、MediaDRM、MediaFormat、MediaExtractor、AudioManager等，如同其他框架，Android允许开发者通过简单的代码构建播放器。
AVFoundation作为苹果公司在iOS和macOS X上对多媒体操作的库，其核心载体是AVAsset，一个Asset可指代一个文件或者用户库内的一个对象，AVURLAsset则实现通过URL定位的多媒体资源，另提供AVPlayer、AVPlayerItem、AVPlayerLayer等类。上层提供AVKit用于简化视频应用的创建过程，如果没有过多定制化需求，则可以直接使用，否则需要直接运用AVFoundation提供的功能，如Core Audio（处理所有音频事件）、CoreMedia（提供音视频帧处理的数据类型和接口）、CoreAnimation（动画相关框架，封装了OpenGL和OpenGL ES功能）等。由于iOS和macOS X的封闭特性，围绕AVFoundation定制的环节和必要性相对较少，更多情况下，应用开发者会选择符合标准的HLS流媒体分发，在播放时使用自带播放器。