元件Elements，通过连接一系列的元件，数据流在各个被连接的元件之间传输
Bins箱柜是可以装载元件elements的容器
管道Pipeline是Bins的一个特殊子类型，可以操作包含在它自身内部的所有Element
Bins本身又是Elements的子集，可以像操作Elements一样操作Bins
可以通过改变Bins的状态，来改变Bins内部所有Elements的状态
Bins可以发送总线消息给它内部的元件，包括error messages, tag messages, EOS message
Pipeline是高级的Bins，设定Pipeline的播放或暂停状态，数据流将开始流动，直到被停止或数据播放完毕
Pads用于连接多个Elements, 从而能让数据流在这样的链接中流动
Pads可以看做是一个Elements插座或端口，2个Pads链接成功的条件是，2个Pads允许通过的数据类型一致的时候才被建立
caps negotiation设定数据类型
GstCaps描述数据类型
gst-inspect-1.0 #列出所有的工厂对象
gst-inspect-1.0 <factory-name> #列出特定工厂对象
gst_plugin_feature_get_name(GST_PLUGIN_FEATURE(factory)) #获取工厂元件的name
gst_element_factory_get_klass(factory) #获取工厂元件的类别，分类
gst_element_factory_get_description(factory)) #获取工厂元件的描述
工厂元件包含了元件所能产生pads的详细描述及其功能(pads所支持的媒体类型)
链接不通的元件之前，需要确保他们被加到同一个Bins或Pipeline,如果要链接在不同Bins中的Elements或pads，将使用精灵Pads
Elements状态，
GST_STATE_NULL #回收该元件所占用的资源
GST_STATE_READ #得到所需的全局资源，数据位置置零
GST_STATE_PAUSED # 可以修改流的位置，读取或修改流，时钟是禁止运行的。能播放视频第一帧
GST_STATE_PLAYING #除了运行时钟外，和上面paused状态一样。gst_element_set_state()改变元件的状态，它在内部可能经过一些中间状态
开启新线程处理数据，可以使用GstBus在pipeline线程和应用程序线程交互信息
创建Bins:元件工厂创建Bins, gst_bin_new(), gst_pipeline_new()
gst_bin_add() #往Bins中添加Elements
gst_bin_remove() #移除Bins
往bins中添加一个elements,bins和elements产生所属关系
把一个elements从bins中移除后，elements自动被销毁
销毁bins，the elements of bins 同样被销毁
bus是一个简单的系统，它采用自己的线程机制将一个管道线程的消息分发到一个应用程序
bus优势：应用程序不需要线程识别即便gstreamer已经被加载了多个线程
每一个pipeline默认包含一条bus，应用程序只需要在总线上设置一个类似对象的信号处理器的消息处理器，当主循环运行的时候
总线将会轮训这个消息处理器是否有新的消息，当消息被采集到后，总线将呼叫相应的回调函数来完成任务
创建消息处理器来帧听管道：gst_bus_add_watch(), gst_bus_add_signal_watch()
自己侦听总线消息：gst_bus_peek(), gst_bus_poll
消息类型Message types
所有的消息都有一个消息源，类型和时间戳。这个消息源用来判断有哪个元件发出消息
GError,提取错误消息，gst_message_parse_error(), gst_message_parse_warning(), gst_message_parse_info()
EOS, end-of-stream
Tags, gst_message_parse_tag(), gst_tag_list_free()
状态转换，当成功的转换状态时发生消息 gst_message_parse_state_changed()
Buffering, 当缓冲网络数据流时发送此消息gst_message_get_structure()返回buffer-percent属性
Element message,
-----------------------
Pads,是Elements对外的接口，数据流从一个element's source pad to another element's sink pad
pads's capabilities 决定了一个element所能处理的媒体类型
pad的类型由2个特性决定，它的数据导向direction和实效性availability，时效性比导向复杂的多
pad可以拥有三种类型的时效性：永久型always, 随机型（动态）sometimes, 请求型on request
永久型always pad一致存在
随机型（动态）sometimes pad只有在某种特定的条件下存在
请求型on request pad 只在应用程序明确发出请求时才出现
---------------------
一个元件被创建时不会立刻产生所有将要用到的pads, ogg(vorbis, theora)检测到元数据流时为每个元数据流创建动态pads,在流终止时删除pads
gst_element_get_request_pad() #从一个Element中得到一个pad
gst_element_get_compatiable_pad() #得到一个兼容性pad
capabilities:描述能够通过pads的数据流，pad的功能。
对于pad模板，pad的capabilities是当通过该pad模板创建一个pad后，该pad允许通过的媒体类型
pad的功能通过GstCaps对象来描述。1个GstCaps包含1个或多个GstStructure。1个GstStructure描述1种媒体类型。
1个被数据流通过的negotiated pad存在功能集， 每种功能只包含1个GstStructure.结构中只包含固定的值，上述约束不对尚未有数据流通过的unnegotiated pads或pad模板有效
gst_caps_get_structure() #得到一个功能的GstStructure
gst_caps_get_size() #得到一个GstCaps中的GstStructure数量
simple caps简易功能是指仅有一个GstStructure
pad的fixed caps固定功能是指仅有一个GstStructure，且没有可变的数据类型像范围换列表
两种特殊功能any caps, empty caps
gst_caps_new_simple()# 创建你自己的GstCaps
当使用gst_element_link_filtered()时，gstreamer会自动创建一个capsfilter元件，将其加入到你bins或pipeline中
并插入到你想要交互的两个元件间
在两个pads间创建一个更精确的带过滤连接的功能集时，你可以用的一个更精简的函数gst_caps_new_full()
----------
管道的数据流由缓冲区和事件时间组成，缓冲区包括实际的管道数据。事件包括控制信息，如查找流的终止信号
源element会创建1个新的buffers， element会把buffers's的data传递给下一个element,不需要自己处理缓冲区，element会自己处理
buffers构成：指向某块内存的指针， 内存的大小， 缓冲区的时间戳， 引用计数
-----------
Querying:主要用来请求数据流中一些与处理轨迹相关的特定性质，包括流的长度和当前位置信息
gst_element_query_position()
gst_element_query_duration()
gst_element_query()
在内部，查询会发送给接收端，然后一直向后分派，直到有一个元件能够处理它
事件定位：包含播放率palyback rate,定位偏移格式seek offset format(一些偏移的数据单元：时间，音频样本，视频帧或一串字节)
可选的查询标志，eg是否清空内部缓冲区
查询在PLAYING或PAUSED状态才被执行并返回结果。当处于PLAYING状态,管道会自动暂停，执行查询，然后将重新置位，再回到PLAYING状态。
------------------
元数据
2种类型：一种是流标签，非技术角度说明了流的内容，作者，标题，所属专辑
另一种是流信息，技术角度说明流的属性，包括视频大小，音频采样率，编解码器
标签系统处理流标签，流信息可以从GstPad获取
获取流信息，需要访问获取流信息的Pad
读取标签通过总线实现，通过监听GST_MESSAGE_TAG来处理它们
GST_MESSAGE_TAG可能在管道中被多次发送，归因于应用程序将所有的标签都放在一起，连续显示给用户
更好的办法是gst_tag_list_merge()，载入一首新歌的时候，确保高速缓冲存储器为空，或收听网络广播没几分钟清空一次cache
同时确保GST_TAG_MERGE_PREPEND是在合并模式，这样后来的新标题就会比原来的优先显示
写入标签通过GstTagSetter接口实现，这需要管道中有一个支持标签设置的元件
通过gst_bin_iterate_all_by_interface()来查找管道中是否有元件支持标签的写入，通常查找得到的元件都是编码器或混合器
管道中的标签都受到保护，这表示即使你将一个带有标签的文件转换成另外一种媒体类型，新的媒体也支持这个标签
gst_element_make_from_uri()让source element或sink element支持特定的uri
-----------
一个元件就是继承于 GstElement的一个对象
仅仅写一个新的元件并不够，为了使GStreamer 能够使用它，你必须将元件封装到一个插件中。一个插件是一块可以加载的代码，
通常被称为共享对象文件（sharedobject file）或动态链接库（dynamically linked library）。一个插件中可以包含一个或若干element
箱柜的主要职责是调度它包含的元件并使得数据流更平滑。
热插拔（autoplugger）元件是另一种箱柜，它可以动态的加载其它元件，并将它们连接起了形成一个可以处理两个任意流的滤镜。
GStreamer充斥着插件的概念，即使你只使用到一些标准的包。核心库中只有少量基本函数，其它所有的功能都由插件来实现
pad是用来在元件间协商连接和数据流的。可以看作元件间互相连接的“接口”.
数据流通过这些接口流入流出元件。Pad具有特殊的数据处理能力:
pad可以限制通过它的数据类型。只有当两个衬垫允许通过的数据类型兼容时才可以将它们连接起来。
缓冲区同样包含描述缓冲区内容的元数据（metadata）。一些重要的元数据类型有：
·一个指向缓冲区数据的指针。
·一个标识缓冲区数据大小的整型变量。
·一个指示缓冲区的最佳显示时间的时间戳。
有些特殊的元件创建指向特殊内存的缓冲区。例如，filesrc 元件通常会（使用 mmap()）
将一个文件映射到应用程序的地址空间，并创建指向那个地址范围的缓冲区。这些由
filesrc创建的缓冲区具有和其它通用的缓冲区一样的行为，唯一的区别是它们是只读
的。释放缓冲区的代码将自动检测内存类型并使用正确的方法释放内存。
另一种可能得到特殊缓冲区的途径是向下游同伙（downstream peer）发出请求。这样得
到的缓冲区称为downstream-allocated 缓冲区。元件可以请求一个连接到源衬垫的同伙
创建一个指定大小的空缓冲区。如果下游元件可以创建一个正确大小的特殊缓冲区，它
将会这样做。否则，GStreamer将会自动创建一个通用缓冲区。接着，请求缓冲区的元件
就可以将数据拷入缓冲区，并将缓冲区 push给创建它的源衬垫。
GStreamer使用一个类型系统来保障流经元件的数据格式是可识别的。当连接元件中的衬
垫时，类型系统对于确保特定的参数有着非常重要的作用，这些参数对正连接的元件间
的衬垫的格式匹配有着特定作用。元件间的每一个连接有一个指定的类型和可选的属性集。
gst-inspect-1.0 [OPTION...] [PLUGIN|ELEMENT]
OPTION:
plugin 一个动态库就表示1个插件，也代表1个element。/usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstaudiotestsrc.so
element audiotestsrc
--help
--gst-info-mask
-a, --print-all #Print all plugins and elements
--print-plugin-auto-install-info #打印指定插件提供的功能的机器可解析列表。与外部自动插件安装机制结合使用很有用。
--gst-debug-mask #GStreamer debugging flags to set
--gst-mask=FLAGS #GStreamer info and debugging flags to set
--gst-plugin-spew #加载插件时，出错输出标志被设置
--gst-plugin-path=PATH #Add directories separated with ':' to the plugin search path
---------------------
X window 是UNIX 和Linux系统上的图形界面系统。1984年，麻省理工学院与EDC制定了Athena计划，这就是X window的第一个版本
GTK+是建立在GDK（GIMP Drawing Kit）基础之上的构件库
GDK是Xlib的包装程序，GTK+在显示构件时调用GDK，GDK是依赖于平台的应用编程界面API