GStreamer优缺点

http://www.doc88.com/p-8985391206739.html

2.1.2. “一个目标”媒体播放器/媒体库

典型的MPEG播放器可以播放MPEG视频和音频，多数的播放器实现了完整的底层构造来达到他们的唯一目标：播放。没有一套有效的机制可以提供对于音频和视频数据过滤和效果处理，更没有制定在视频或音频数据中添加滤波器或特殊效果的任何规定。

如果你希望将MPEG-2视频流转为AVI文件，那么你的最佳选择是，将所有的MPEG-2解码算法从播放器分离出来，并复制到你的AVI编码器中，因为这类算法不能简单的在应用程序之间共享。

开发人员曾经尝试着创建一个可以处理多种媒体类型的库，但由于缺乏通用的API，所以如何集成就成了重要的工作了。因为在集成的过程中，我们需要关注一些特殊的媒体类型(avi文件，libmpeg2，...)，而集成这些媒体类型文件需要一个统一的接口。GStreamer允许将这些库与通用的API一起打包，这样就简化了集成和复用。

2.1.3. 没有统一的插件管理机制

典型的播放器对于不同的媒体类型会有不同的插件，两个媒体播放器会实现各自不同的插件机制，所以编解码器不能方便的交换。每一个典型的媒体播放器的插管理件系统是具有其特定应用程序的需求。

缺少统一的插件机制，已经严重阻碍了二进制编解码器的发展，因为没有一家公司希望将代码移植到不同的插件机制。

GStreamer当然也采用自己的插件系统，它为插件开发者提供了一个非常丰富的框架，从而保证这些插件能够广泛应用，并与其他插件能够无缝的交互。GStreamer为插件提供的框架是非常灵活，它足以满足大多数插件的需求。

2.1.4. 拙劣的用户感

因为上述问题的原因，使得应用程序开发人员将相当多的时间花在如何处理后端、插件机制等等问题上。从而耽误了大部分的项目时间，这样就常常导致后端和用户界面都只完成了一半，于是就导致了拙劣的用户感。

2.1.5. 没有网络透明度的规定

当前还没有一个底层框架出现，来允许对网络透明媒体的操作。有趣的是，一个分布式的MPEG编码器能够复制非分布式编码器的相同的算法。

并没有关于使用 GNOME 和 KDE 桌面平台的技术的规定被制定出来，因为GNOME 和 KDE 桌面平台本身还在改进和完善，所以很难将多媒体恰当地集成到很多用户的环境中。注意到GStreamer还提供很多种方法，这些方法提供将GSreamer与不同的桌面系统进行集成(见附录里的集成一节)，而这些方法往往都不是网络透明化。

GStreamer内核在最底层没有采用网络透明技术，只是在顶层加了作为本地使用，这就是说，创建一个核心组件的包就变得比较容易了。GStreamer允许管道在TCP协议上分离，使用tcp插件来实现GStreamer数据协议，这个被包含在gst-plugins模块，目录gst/tcp

2.1.6. 与Windows™的产品还存在差距

我们要想看到Linux桌面系统的成功就要立足于可靠的媒体处理。

我们必须为商业编解码器和多媒体应用扫清障碍，这样Linux才能成为多媒体领域的一个选择。

2.2. 设计目标

我们将阐述在GStreamer开发中的目标．

2.2.1. 结构清晰且威力强大

GStreamer提供一套清晰的接口给以下一些开发人员：

l 希望构建媒体管道的应用程序员。程序员可以使用一系列强有利的工具来创建媒体管道，而不用去写一行代码，从而使得复杂的媒体控制变得非常简单。

l 插件程序员。GStreamer向插件程序员提供了简洁而简单的API来创建self-plugin(自包含)插件，同时还集成了大量的调试和跟踪机制和工具。GStreamer也提供了一系列现实例子。

2.2.2. 面向对象的编程思想

GStreamer是依附于GLib 2.0对象模型的，熟悉GLib或者旧版本的GTK+的程序员对GStreamer将会驾轻就熟。

GStreamer采用了信号与对象属性的机制。

所有对象的属性和功能都能在运行态被查询。

GStreamer与GTK+的编程方法非常相似，需要对象模型，对象所有(ownership of objects)，参考计算（reference counting）...

2.2.3. 灵活的可扩展性能

所有的GStreamer对象都可以采用GObject继承的方法进行扩展。

所有的插件都可以被动态装载，可以独立的扩展或升级。

2.2.4. 支持插件以二进制形式发布

作为共享库发布的插件能够在运行态直接加载，插件的所有属性可以由GObject属性来设置，而无需(事实上决不)去安装插件的头文件。

我们更多的关注在插件能够独立化，运行的时候还需要很多与插件相关的因素。

2.2.5. 高性能

高性能主要体现在：

l 使用GLib的g_mem_chunk和非模块化分配算法使得内存分配尽可能最小。

l 插件之间的连接非常轻型(light-weight)。数据在管道中的传递使用最小的消耗，管道中插件之间的数据传递只会涉及指针废弃。

l 提供了一套对目标内存直接进行操作的机制。例如，插件可以向X server共享的内存空间直接写数据，缓冲区也可以指向任意的内存，如声卡的内部硬件缓冲区。

l refcounting和写拷贝将memcpy减少到最低。子缓冲区有效地将缓冲区分离为易于管理的块。

l 使用线程联合(cothreads)减少线程消耗。线程联合(cothreads)是简单又高速的方法来切换子程序，作为衡量最低消耗600个cpu周期的标准。

l 使用特殊的插件从而支持硬件加速。

l 采用带有说明的插件注册，这样的话只在实际需要使用该插件才会去装载。

l 所有的判断数据都不用互斥锁。

2.2.6. 核心库与插件(core/plugins)分离

GStreamer内核的本质是media-agnostic，我们了解的仅仅是字节和块，以及包含基本的元件，GStreamer内核的强大功能甚至能够实现底层系统工具，像cp。

所有的媒体处理功能都是由插件从外部提供给内核的，并告诉内核如何去处理特定的媒体类型。