多媒体基础学习

一直想写点关于多媒体学习的东西，又感觉自己掌握的东西太浅，太杂，写不出东西。

网络上的资料其实已经很全面了，在学习的过程感觉虽然不少精品，但是却不够精品，而且有些东西也不太适合初学者。

所以决定写点东西，当做自己的学习笔记。把网络上的资料整理一下，也顺便看看自己的理解是否有误，只针对初习者的笔记。

先写提纲

1，视频容器与编解码器的区别

2，视频播放的基本原理

3，颜色空间的概念及转换

4，视频压缩的基本原理，一些常见压缩算法的概念

5，常见容器的解析avi/mp4/mkv/ts/flv

6，render的一些概念和可用库（sdl/directfb/fb/....)

7，一些应该学习的开源框架与库用途和差别（vlc/ffmepg/mplayer/gstreamer/openmax/mpc/ffdshow/directshow...)

8，开源库的编译（vlc/ffmepg/x264/xvid/...)

9，图片解码库的使用（libjpeg/libpng/...)

目前想到的就是这些。以后如果想到新的，再补充。

其实学习这些东西，更多的是开源库的使用，之前学习都比较粗糙，找到相关的代码，然后编译，看结果。就ok了。

对于工作，实际应该是够用了。学习可以更加深入一些。

1.视频容器与编解码器的区别

这基本是一个老生常谈的东西了，但是我仍然是看了很多资料，加上一点点理解才完全明白了其中的差别所在。

这就像上学时的考试大纲，这种东西要求是识记类型的，没有技术门槛，但是只有你把东西都记住之后，才完全知道书上再说什么。

 

一，容器的概念

什么叫容器，从字面的含义来说，能放东西的东西，就叫容器。

打个比方就像桶，可以装水，可以装油，可以装硫酸，等等。

一部电影，不可能只有图像，还有声音，可能还会有字幕，还会有文件作者，加密信息等等。但是我们又不能把这些东西单独存放，这样太麻烦了。所以发明这样一个“桶”，把图像，声音，字幕等等的东西，一股脑放到一个地方，这个“桶”就叫视频的容器。ps:又叫封装格式。

一般来说，文件的拓展名就是容器名。比如.avi，.mp4，.flv，.mkv等，就是不同的容器。

 

二，编解码器的概念

通常来说，图像信息和声音都很大，如果不压缩存放，空间浪费太严重，而且也不利传输。

为了解决这个问题，人们发明了编码器，说白了，就是用来压缩这些信息的。

不同的编码方式，就是不同的编码器。例如mpeg-1,mpeg-2,mpeg-4,h.264，以及还是草按的h.265

这个东西之所以有很多种类，多半的原因就是各个大厂商为了保护自己的利益，定义一些标准，然后推广，就可以坐吃专利，一本万利，何乐而不为？

 

三，常见的容器类型介绍

不准备写太详细，大多数东西只是做一个提示，可以参考维基百科的介绍，写得太多反而会使人迷糊，只写自己知道的，详细的可以参考资料，只是做一个提纲挈领的东西。

avi

(audio video interleave)，是微软在1992年推出的一种多媒体文件格式， 比较老了，对目前的基于网络流播放的方式力不从心。

mp4

标准规范是ISO/IEC 14496-14，由mpeg组织规定。youtube的视频很多是这种封装格式。

mkv

一种由开源组织规定的容器类型，链接是http://www.matroska.org/，现在的高清电影一般都采用这个格式。

ts

同样由mpeg组织规定，一般用于数字电视广播中，平时从网络下载来的电影很少用这种格式封装的。标准是13818-1

rmvb/rm

这是一个由商业公司（RealNetworks）自己定义的，网络比较流行，标准不公开，所以播放这种视频只能用专利播放器。

wmv

不多说了，微软定义的封装格式。

flv

视频网站类似优酷，土豆等，都用这个容器来存储视频，很好的保护原始地址，不容易被下载到，从而起到保护版权的作用。由adobe公司开发。

其他的比如3gp，asf，webm，不一一介绍了。

如果想了解更多。

http://zh.wikipedia.org/wiki/MPEG-1，这个链接下面有个表格，里面的东西非常全面。

 

四，常见编码格式

mpeg-1

mpeg组织最早规定的视频编码格式，标准是iso-11117，主要是vcd在用。

mpeg-2

mpeg组织规定的压缩标准之二，主要用于DVD，数字电视广播（DVD)，标准是iso-13818系列。

mpeg-4

mpeg组织规定的压缩标准之三，这里有不少东西要交待，这三个标准其实是随着计算机运算能力越来越强而逐渐产生的，所以压缩的视频质量越来越好，但是算法复杂度却越来越高， 不过计算机能力越来越强，这都不算大问题了。

有一个有意思的事就是，为什么没有mpeg-3呢？其实原本是有mpeg-3的，但是mpeg组织在写标准时发现，mpeg-2实在太优秀的，mpeg-3推出的目标，他都能做到，所以就这个项目砍掉了。所以mpeg系统的标准，从1，2，4，就直接到了7，就是一个权衡。mpeg组织内部有两派，一是按1，2，3，4，5这样来。另外一批人觉得，1，2，4，后面按道理怎么也是8啊。折中一下，就是mpeg-7了。

ps:mp3是指mpeg-1音频压缩的layer 3.

h264/avc/mpeg-4 part 10

大名鼎鼎的264。

由mpeg和itu-t联手组成了一个叫JVT（Joint Video Team）的组织制定的。

这个东西容易使人迷糊，因为他得名子太多了。又叫mpeg-4 part 10，又叫avc，又叫h264，而且实际上，基本就是一个东西的不同名子。

vc-1

微软定义的压缩标准，不过后来开放出来了，由电影及电视学会（SMPTE）组织标准化。

realvideo

私有标准，木办法，这个东西人家就是私有的，在国内喜欢盗版的地方，大家都不介意，所以市场比较大，其实在北美那边，这种东西，不太多。

这里要注意区别，rm/rmvb是容器类似，realvideo是压缩标准。如果说有共同点，那就是：都是由一家公司提供的。呵呵

avs

最后要说的是，国产标准，没太研究过，不知道到底如何，由国内的联合信源公司开发，提交成国家标准。貌似广电总局已经强制机顶盒一定要支持这种压缩格式，以强推这种标准。就像tds-cdma，wapi，还有移动数字电视的方式一样，行政压迫。呵呵。

不好说前景。

同样，更多信息可以参考我前面提供的链接，各种冷门的容器，编码器，维基都介绍，可真谓是知识宝库啊。

 

ok，终于写完了一篇了，却感觉挂一漏万。唉。想了很多，却总感觉写得极不全面。

先这样，以后如果有需要补充的，再修改。

2.播放器的基本原理

播放器解决了视频播放的问题。通常来说，解决问题最好的办好就是大而化小，小而化无。因为整个播放过程是一个复杂的过程，所以播放器也采用分而治之的办法。

简单来说，这个大问题可以分解为四个小问题。

1，数据接收;2，数据解析;3，数据解码;4，数据输出。

我会对mplayer和vlc这两个开源播放器的代码结构来说明这四个问题。

一，数据接收（access)

自然，我们不能无中生有，要处理数据，总要有数据来源才行。但是数据来源的渠道有很多种。

可能是硬盘文件，可能是dvd光盘，也可能是http/httplive数据包，也可能是rtp数据包（vod)，或者ftp，广播电视的ts流等等。

所以第一步我们要处理的问题就是如何把不同的数据来源统一一个接口。这需要不同数据包解析器，也就是实现不同的协议来满足这个需求。

对于mplayer，相关的代码在strearm，

对于vlc，相关的代码在/modules/access

查看代码目录，里面文件名可以和我们前面说的一些数据来源一一对应。所以如果我们需要实现某种协议，大抵是可以从这里获取一些实现思路的。

二，数据解析(demux)

有了数据了，我们还要解析这些数据。

为了方便媒体文件的传输，我们要把音频，图像，同步信息等等一堆信息放到一起（就是上一篇说的容器），这个过程就是mux(multiplex)。

但是为了方便媒体文件的处理，我们又需要解复用demux（Demultiplexer)

container是为了解决的传输而诞生的，demux就是为了解析而诞生的。

不同的容器需要不同的解析器，就是不同的demux接口，为了方便编程，我们同样需要统一接口。我们来看看mplayer和vlc是如何做的。

mplayer把相关代码放在了libmpdemux里面。

vlc把相关代码放在/modules/demux里面。

这两个代码统一各种容器的解析方式（就是我们常见的avi，ts，mkv的解析）。

不过需要注意的是，这些代码很大一部分都是warp的ffmpeg/libavformat里面的代码。

三，解码（decode)

上面那个过程把音视频数据分离，我们得到的数据可能是mpeg-2/h.264压缩的视频，也可能是mp3/aac/ac-3等音频数据。

但是这些数据都是压缩过的，我们知道，屏幕是由一个一个的点结成的，这一个一个点又是由rgb来描述的，声卡是处理一个一个音频帧的。

这个过程我们要解决的问题就是把压缩过的数据还原出来。如何还原？没错，靠我们的解码器。

上一篇说了不同的解码标准，现实中的情况是，我们有了一个标准，但是我们可能根据这个标准来实现不同的解码器。就像我们有一张桌子的草图，但是我们做的桌子却有不同的颜色一个。标准有了，实现可以不同。

mplayer把这块代码放到libmpcodecs里

vlc把这块代码放到/modules/codec里。

不过要指出的是，这两块代码同样大部分是在warp ffmpeg/libavcodec。

ffmpeg真是做为神一样库而存在啊。

四，数据输出（render)

准备好了解码后的数据，就差最好一步输出了。

视频通常会解码为yuv数据，音频通常会解码为pcm数据。然后我们把这些数据分别放到屏幕和声卡里，播放过程就算完成了。

同样，数据输出也有很多渠道，也需要统一。

图像可能会输出到sdl，x11或者framebuffer，或者directfb，也可能是wingdi。

音频可能会出到oss，alsa，等等。

为了统一这些，vlc和mplayer同样warp了一些库，

mplayer放到libvo与libao

vlc放到/modules/audio_out与/modules/video_out。

4，视频压缩的基本原理，一些常见压缩算法的概念

自己的这个笔记，废了好久，还是要坚持写下去，虽然现在看来，质量不太高，而且很多东西貌似没有说到位，只有自己才看得懂，明显不是技术普及的方式。

先说基本原理，这个基本就是抄书了，因为不是做科研的，很多东西都是人们用了很多年才逐渐总结出来的。

对于算法研究而言，本身就是要先知道哪个地方可以努力，哪些地方行不通。这些原理，就是指明方向的。

一.视频压缩的可行性

1.空间冗余

一幅静态图像，比如人脸。背景，人脸，头发等处的亮度，颜色，都是平缓变化的。相邻的像素和色度信号值比较接近。具有强相关性，如果直接用采样数来表示亮度和色度信息，数据中存在较多的空间冗余。如果先去除冗余数据再编码，表示每个像素的平均比特数就会下降，这就是通常说的图像的帧内编码，即以减少空间冗余进行数据压缩。

2.时间冗余

视频是时间轴方向的帧图像序列，相邻帧图像的相关性也很强。通常用降低帧间的方法来减少时间冗余。采用运动估计和运动补偿的技术满足解码重建图像的质量要求。

3.符号冗余

用相同码表示概率不同的符号，会造成比特数的浪费。比如10，11，13三个数，如果我们都用1bytes来表示，就是3bytes(即3×8 = 24bits)，但是如果我们表00b表示10，01b表示11，02b表示13，这样，三个数合起来才用了6bits，较之前可以节省18bits。

可变长编码技术的原理就如此，概论大的用较短的码字，概率小的用较长的码字。

4.结构冗余

对于图像内部，各个部分也存在某种关系。我们可以通过这种关系，减少信息的码字表达。比如:分形图像编码

5.视觉冗余

1），人眼对彩色信号的亮度分辨率高于色彩分辨率，比如rgb-->yuv就是这个原理

2），人眼对静止图像的空间的分辨率大于运动图像的分辨率。

3），人眼对亮度的细小变化不敏感

4），中心敏感，四周不敏感。

其实我们虽然知道了这些，我们知道有冗余，但是如何把这些冗余找出来，是个很复杂的过程。也是我们的算法不断追求的过程。

上面的一段，是所有视频压缩标准的基石。mpeg2,mpeg4,h264,h265这些标准，与其说他们是标准，不如他们提供了一些算法的组合，或简单或复杂，当然简单的算法压缩掉的冗余小，复杂的压缩掉的冗余大。通过算法找到冗余信息在哪，然后压缩掉，实现数据量的减小。这就是我们的目录。

更近一步的说，就是我们如何找出数据的相关性。

二，常见算法的名词解释

大的分类有两种，一个变换，一个是编码。

先说变换

我们要找出信号的相关性，时间上不好找怎么办，变换到另外一个空间上去。这就是我们在信号与系统，数字信号处理，高等数学得到的结论

变换

傅里叶变换

walsh-hadamard(沃尔什哈达玛变换）

正弦变换

余弦变换----应用最广

斜变换

哈尔变换

k-L变换

小波变换

对于这些变换来说，很多东西只在数学上有意义，对于工程来说，或者没有快速算法，或者变换后相关性比较低，或者其他原因。只有余弦变换是最最广泛的，为了减小我们的学习压力（当然如果你是要对比其中的差异的另当别论），我们只掌握余弦变换就可以了。

编码

又分无失真编码与限失真编码，从名字上我们就可以看出差异了。呵呵，不多解释

无失真编码的种类：

哈夫曼编码，算术编码，游程编码

限失真编码

预测编码，变换编码，矢量量化，基于模型的编码。

对于编码这块，上述的算法，基本要全部掌握才行。

jpeg/mpeg2先用了游程编码减小的0这个数占用的比特位，然后用了哈夫曼压缩。

h264用了算术编码来做最后一道压缩工序

运动补偿与运动估计，用到预测编码。

mpeg4用到了基于模型的编码

变换完成后，进行了矢量量化。

6，render的一些概念和可用库

一，概念解释

什么是渲染？这是高大上的说法，翻译成正常语言，就是把图像缓冲区的数据显示到屏幕的过程，就是渲染。

 

原理说白了很简单，但实际操作中有太多因素需要考量。

OS/硬件提供的加速机制/解码后图像数据格式/字幕数据的格式。。。。

刚开始查找资料时，我总是试图找到所有的渲染方式，后来发现这实在错的比较离谱。因为说到底，这是一个图形学的问题：如何在计算机屏幕上绘图。不同的图形库有不同的绘图接口，太多的厂商有自己的图形库，根本不可能穷举出所有的图形库。我们只能讨论一些相对主流的方式。另外去找所有的图形渲染方式也是没有意义的，因为他们的理念大体上又是差不多的，只是API不同。唯一的要求是，你要画的足够快，因为如果你想一张张图像看起来是连续的，那么速度要达到24帧以上。当然，对于一些特殊应用，比如视频会议，15帧的速度不会让人有卡顿感，这个帧数也完全Ok。

二，问题的概念空间与一些解决方案

说完了，回到开始的问题，如何渲染。

这里又有两个问题需要解释：

1.图像缓冲区里面的数据是什么样的？RGB还是YUV，又是哪种RGB，哪种YUV?

2.如何把缓冲区的数据搬到屏幕？CPU，普通的2D加速，还是GPU，用GPU时，是OpenGL还是D3D？

 

第一个问题：

这里我们只说几个常见的。这里的图像缓冲区，特指解码后的数据，而非对应屏幕显示的那块。因为对于目前的真彩色显示器来说，屏幕对应的数据只有一种，就是RGB888。无论你给到的数据如何，传输到屏幕点亮色点的数据都会被驱动/硬件/总线给处理成这种格式。这是由屏幕的物理属性决定的，物理屏幕就是TTL电路点亮的一堆小灯。

常见的有RGB888/RGB565/YV12/I420p。

ps:实际解码器出来的都是YUV数据，如果得到RGB数据，通常也都是解码器后面加了一步YUV2RGB的转换，不过通常我们也会把这块功能算成是解码器的。不过不绝对，需要看lib的作者如何看待这个问题。

第二个问题：

1.纯粹的CPU（现在貌似很少有这种了），就是一个一个的往屏幕上画点了，一个pixel一个pixel的画，不太常见，也比较慢，因为操作内存太过频繁。有些库封装了overlay/bitblt等操作，虽然看起来像CPU在做，实际上已经调用了2D加速了。

2.用2D加速的

Overlay

以前看资料，老看到Overlay什么的东东，找了很久，似乎也没有谁专门给出一个标准定义，说什么才叫Overlay。说下我的理解，Overlay通常是一个硬件意义上的名词，因为屏幕上的东西，通常有很多层次，Overlay可以做的就是直接把这层放到所有图层上面。通常的用法是YUV数据直接给屏幕，Overlay硬件会替你做YUV2RGB转换。这个词貌似来自ms的directshow，有什么主表面，离屏表面，overlay之分，实际上就是硬件图层的意思。貌似有些硬件可以支持RGB Overlay，很少见。有些图形硬件可以支持多个Overlay图层，也就是说，你可以使用Overlay同时在屏幕上显示几个不同的视频。视频监控的宫格多半就是这样来的。

嵌入式里面，Overlay还有一种常见做法，比如：一些有很高优先级的提示，要给用户，这时就得把普通的提示框做成YUV的，然后提示显示出来，可以直接盖到所有的图层上去。

关于模拟Overlay，呵呵，凌乱了吧，实际上就是接口叫xxxOverlay，实际上是把YUV转成RGB，然后画点的方式显示，SDL中有这种接口。

最常见的Overlay类型是YV12，一是数据量小，二视频压缩的标准有关，因为Mpeg2/h264等标准，都强制要求这种格式，当然这两点是相符相成的。

优点就是快，缺点也比较明显，如果要做视频图像后处理，比如放大缩小，人脸识别等操作，会比较麻烦。

Bitblt

比较常见的2d加速方式，把内存数据的数据直接传输到屏幕，或者搬到另一块内存中（内存拷贝）。

blit是个有渊源的词语，这个词的本意就是块（block）移动（transfer）的缩写blt，因为这个缩写缺少元音不好读，所以后来加上了i，就变成blit。

实际上我搞不清这和DMA有什么区别，希望有人指点一下区别。难道区别仅仅是BitBlt可以同时缩放/旋转，而DMA不能？

另外与Android提出的CopyBit有区别么？我看没啥区别啊。

优点是在内存拷贝时，可以同时做缩放/旋转，缺点是只能用RGB格式。

(2014.03.30更新：

1.查了一些资料，看了一下bitblt实现原理，除去缩放/旋转的算法之外，涉及到内存搬移的应该是调用memcpy实现的，从这个角度来看，是用到了dma功能的，看来是没有什么区别的。只是memcpy的实现通常是考验硬件性能和程序员水平的地方。

2.从copybit规定的interface来看，实际就是bitblt，估计只是bitlt这个单词是ms提出的，google觉得不爽，起个新名子而已。

实际android到了4.0之后，已经取消掉了copybit HAL module，2d加速全部采用了GPU操作。在android 2.3代码里还残存着一些痕迹。）

3.GPU

其实OpenGL和D3D就是GPU在软件接口层面上的抽象。用opengl和d3d显示视频通常都是用texture方式来实现的，把一帧一帧图像生成纹理数据，然后贴到vertex上去。

简单解释一下就是，先建立顶点坐标，再建立纹理坐标，再把顶点坐标与纹理坐标一一映射，完成贴图。具体的要看一下OpenGL编程书籍了，这实在是一个复杂的题目。

先把屏幕四个点当成两个三角形（因为3d api用三角形来表示平面，当然多边形也支持，但遇到不支持的情况，用两个三角形就可以组成一个矩形），把数据的一个点一个点对应到这个矩形上，就显示了一帧。因为GPU通常是并行操作，像素生成率通常也足够高。

这块了解不够多。不多说了。

三，常见的库

这个通常又与OS有关系了，讨厌死了。

先说Windows，又分几个层次。先从底层说起。

纯api就是

Windows GDI，windows平台对图形硬件的抽象，很多年了，比较成熟，效率应该比较OK。

DirectDraw，这个封装的就是Overlay的操作接口，但是微软已经停止支持了，不建议使用。

D3D，微软的3D API，门槛比较高一些。

Direct2D，层级和GDI貌似差不多，Win7时代出现新玩意，看过一些资料，说这套API是取代GDI的，不过貌似微软已经尾大不调了。

上述几个API，VLC播放器里面都有一些具体的实现，可以看一下下。

另外就是DirectShow中的filter级别的。

VMR7，底层用DirectDraw封装的，资料说只有XP好用，更老更新的平台都不支持。

VMR9，底层用D3D实现，还在支持。

EVR，vista时代出现的东西，好像也是D3D做的（微软你到底要闹哪样。。。。这么多选择）

其实dshow还有什么overlay mixer，video render之类的filter，我觉得都没有跑出我上面说的范围。

说Linux吧。

X-window的api算一种，虽然一直用X，但对X的超多bug也很不满，从来没看过。。。（吐血）

DirectFB，通常在嵌入式平台才会使用，桌面平台上极少见到，抽象了几乎所有的2D加速机制，接口操作和DirectDraw几乎一模一样。

直接用FrameBuffer提供的接口，嵌入式多见，不过通常这些接口里面已经封装了Overlay/BitBlt接口，不要只见树木不见森林就好。

跨平台的

SDL，算是比较常用的，API的使用还比较简单，但是看代码真心觉得太乱了，不过人家是跨平台的，代码乱真心是难以避免。

 

最后有个比较惨痛的事实，因为你在写播放器时，这些API可能都没用，因为。。。。。你的图形库会再给你提供一套。。。。好吧，懂得原理，很多事情会简单一些。

7.一些应该学习的开源框架与库用途和差别

修bug修得头疼，看看自己的博客，坑挖了一堆，出来混，迟早是要还的，这里先补一个。

刚开始看多媒体这块时，总是发现有新框架，新平台，新名词弄得云山雾绕，为了避免重复google/wiki，我尝试做个总节吧。

之前写过codec与container的区别，这里就不多说了，更近应用层的东西。

这些东西大概有：vlc/ffmepg/mplayer/gstreamer/openmax/mpc/ffdshow/directshow...

这些软件，所涉及的层面和针对的应用场景，系统各不相同，按层次分别说一下。

一.播放器层次

这个层次上，是直接可以用的软件，已经做完了一切工作，如果我们需要用他们，是不需要写一行代码的，编译通过就可以拿来使用了，对于国内这些山寨公司来说，基本就是拿来就可以骗钱的档次了。

包括 vlc/mplayer/mpc，这里我只是简介一下，我就不费劲从维基和官网复制东西了，貌似网上其他文章也都是从这两个地方复制了点东西，毫无营养。

其中vlc与mplayer都是跨平台的，都是起源于linux界的大佬，后来逐渐发展到跨平台了。

vlc，插件机制的播放器，非常灵活，但是总觉得这货速度太慢，不过可移植平台比较多，ios/android/win8。。。。等等都有他的身影。

官网：http://www.videolan.org/

维基：http://zh.wikipedia.org/wiki/Vlc

mplayer，单线程，状态机机制的播放器，比较古老，代码有些凌乱。

官网：http://www.mplayerhq.hu/design7/news.html

维基: https://zh.wikipedia.org/wiki/MPlayer

mpc，是windows平台上的开源播放器，基于filter机制，像qq影音/射手播放器/百度影音/.......一系列windows上的播放器，都是脱胎于这个软件。

这套软件不太爽的一点是，只能在windows上运行，不能移植到其他平台，原因是他的使用了windows的directshow框架。

官网：http://mpc-hc.org/

维基：http://zh.wikipedia.org/wiki/Media_Player_Classic

这里有篇文章，是讲述这些播放器的架构与应用的，非常经典。来自射手播放器的博客

链接：http://blog.splayer.org/index.php/2010/03/%E5%AA%92%E4%BD%93%E6%92%AD%E6%94%BE%E4%B8%89%E5%A4%A7%E5%BA%95%E5%B1%82%E6%9E%B6%E6%9E%84%E7%AE%80%E6%9E%90/

二.框架层次

主要包括gsteamer/directshow/openmax

1.gstreamer是基于gnome的基础类库gobject所写的一套，开源多媒体框架。主要针对于linux，当然windows上也可以使用。

基本设计思路类似于directshow，区别只是

gstreamer基本部件是component（组件，demux/codec/access/等，都可以当成一个组件)，对directshow来说，对应的概念是filter。

gstreamer各个组件的链接是pipe(管道，组件间传递数据，通信的机制），对directshow来说，对应的概念是pin。

对于这个框架一些比较典型应用就是meego/tizen手机平台上的媒体框架。

2.directshow是微软的推出的windows平台上的媒体框架

详细请戳：http://zh.wikipedia.org/wiki/DirectShow

应用比较广泛，像视频监控上位机，也就是pc端，基本上都得用这个了。另外windows平台的播放器，也基本遵行这个框架的一些概念空间。

xvid/x264两个组织，都把自己的算法库给封装了一套filter，方便兼容到这个平台上。

3.openmax

层次比较gstreamer与directshow低一些，主要用来封装解码库，基本的概念空间也是组件，不过通信方式叫什么tunels（隧道）

典型应用就是android手机平台了，呵呵。（好牛b啊）

对这些框架来说，都是为了方便开发应用准备的，与第一个层次区别就是，第一个层次就是一个单纯的应用，而这个层次，只是提供了一些机制，你可以用这些机制做任何你想要的东西

另外觉得这些开源的家伙太能捣腾了，基本类似的概念空间组合来组合去。让我们这些小菜学得学得头大。

三.库

首先要明确的是，库与框架的区别。

一般来说，框架只用写一些回调函数，应用就能跑起来，类似于mfc的button响应，android的oncreate之流。

库，只是一些功能，你需要自己调用起这些功能。

（一个简单的区别方法是，你用不用自己写main函数，呵呵，相当不科学，不过一般是准确的）

好吧，我觉得我也没说清，呵呵。

ffmpeg/ffshow基本属于这个概念层次的。

ffmpeg是上面介绍的东西的老祖宗，软件/框架，都是依赖这个库来实做的，ffmpeg提供了万能解复用，解码功能，他们只是调用这个库，进行自己需要的封装。

ffshow与ffmpeg的关系更暧昧。对directshow的filter概念空间来说，很多filter要自己写，所以有人就站出来做了这事，开源了，ffshow就是这样的东西。

一句话，用ffmpeg与了一堆filter.

8，开源库的编译

开始写时，想把vlc/ffmepg/x264/xvid/都弄一遍，觉得很多代码都要自己编译一下才爽，后来发现，如果不做二次开发，拿dll回来用，足够了，不用费劲自己搞环境。大部分时间大家又想用windows平台下的编译方法，这又更加麻烦了，因为windows的shell环境太弱了，gcc又需要另外装，太麻烦了。

而且想弄的库什么的太多，我乃普通人，学不了这么多东西。另外有太多事情大家已经重复做过很多次，写了很多文章，我不用画蛇添足了。所以我决定打个折扣，只写一些大家不太关心的，但是又有一些人想知道的。

我要是能把264编解都搞定，xvid/ffmpeg又能用得虎虎生风，也不会像现在这样写普及文章了，呵呵。

这个完全是纯操作，按步骤，正常人都行的。

1.VLC

实际上授人以鱼，不如授人以渔。VLC的官方网站实际就有编译方法，就文档这一项，比其他项目强太多了。

链接在此：https://wiki.videolan.org/Category:Building/   选择你需要编译的平台看doc即可。

虽然按照步骤还会有一些问题出现，但是通常这些问题都可以google到。大部分时间，问题都出在autoconf/automake/libtools这套东西上，这个东西实在烂的可以，版本差异又极大，真是无药可救。

我大概说一下我做的过程，这个实际上和你的linux版本有太多关系了。而且我自己都是失败了放弃了很多很多次之后，才逐渐找个规律，然后现在基本都可以一次编译通过。

先装好需要的工具，cmake/yasm/svn/git/cvs，因为vlc编译时，有很多的依赖库会从网络下载，所以有时有些网站被墙时，有些tar.gz无法下载，你就需要自己去下载回来，然后放到contrib/tarballs下面。

% cd contrib

% mkdir native

% cd native

% ../bootstrap

% make

先编译依赖包，因为vlc本身只是一个框架，实际的协议栈/codec/这些库，早就有人开发好了，不用白不用，所以VLC就把这些库拿过来放到自己代码下面了。具体就在contrib/src下有很多。mk脚本，都是配置选项，下载链接之类的东西，在这里。编完依赖，回到根目录，直接make编译成功即可。

2.ffmpeg

 老规矩，告诉一个官方的文档来。

http://ffmpeg.zeranoe.com/builds/

这是一个ffmpeg for win32的编译网站，几乎每隔几天就会编译一个版本出来，如果需要开发，直接拿sdk和bin回来用，就可以了，自己在windows上架cygwin/mingw，真心不是好玩的，我玩了太多次，已经累觉不爱了。

3.x264

直接戳这里：http://download.videolan.org/pub/videolan/x264/binaries/

各种平台都有了，拿回来用吧。不爽的一点就是不知道有些编译选项是否打开，比如我要给ARM编译一个，看来这个需要自己动手编译了。

4.xvid

windows平台也很容易编译，因为这个项目组已经提供了vc项目了。只需一个f5即可。

不过要先装nasm才行。因为有些汇编优化代码是gnu格式的，windows的masm不认识。

一些其他的东西：

　　关于264

　　ffmpeg的代码，只有解码模块，没有编码模块，ffmpeg（这里指命令行工具）虽然能压缩片子，但是这个实际是调用x264实现的。

      x264的代码，主要是一个编码器，并不侧重解码这块，甚至没有完整的解码器实现。

      xvid和divx有一场圣战，详细请戳http://zh.wikipedia.org/wiki/Xvid

      nasm很多时候，开发软件真是非常痛苦，比如开发工具就非常郁闷。汇编的格式还有所不同，导致汇编器不一样，所以masm与nasm就出现了，一个是mirosoft的，一个gnu for win32的。更具体的区别

      http://hi.baidu.com/3100100788/item/819ef992dff650fe28164742

 

好吧，其实开源界的codec代码(FLAC/OGG/VP8/theora.....)实在太多了，真不知道国外怎么那么多高手，我连看都看不明白，他们随便写了一个又一个。不过真实的世界可能是，大公司为了推广自己的技术，派几个人做个开源版本，然后自己卖闭源软件。真是精明啊。

转自 http://www.cnblogs.com/mr-nop/category/369322.html

谢谢作者