3.6 Pads和属性
Pads很关键，代表了单元的出入
口。标示Pads特性的有两个：
l 方向，从单元内角度看，sink收数据，source发数据
l 可用性（availability）
方向好说，只有sink和source两种，可用性是一个新概念。主要代表这个pad是存活期的。
分三种：
l pad一直存在
l 动态存在：有时候有，有时候没有，动态创建和删除
l 响应存在：根据外界要求来创建
这个可用性是针对媒体文件类型的一种简化表示。下面针对这个具体讲述，pad的可用性非常重要。
1. 动态pad
为何会有动态之说？原因很简单。例如播放音频的时候，要动态检测有几路音频，然后再创建对 应的pad。
程序里边应该绑定一个消息处理函数到动态pad的创建通知上。
2. 响应pad
响应用户要求而创建的pad。必须从一个支持创建这种类型的单元中去创建，调用
l gst_element_get_request_pad
这个element必须支持Request这种，这个熟悉由插件注册的时候指定的。
还有一种就是查找相容的pad
l get_element_get_compatible_pad，根据源pad和caps来从单元中找一个相容的。
3. Pad的属性
刚才提到过，查找相容的pad，那么相容是怎么判断和体现的呢？pad有自己的能力熟悉（Capabilities）
pad的能力熟悉是和pad模板以及pad绑定一起的。pad模板估计就是一个pad工厂。
一个pad有很多不同的能力，这个是最原始的信息。但是具体工作后，一个pad要和别的pad协商，大家按照规定的能力办
事。这样，pad的能力就是协商后的能力了。
能力在GST中用GstCaps来表示。
GstCaps含一到多个Gstructure，一个Gstructure代表一种pad能处理的媒体类型。
4. GST中属性和值的表示
GST除了使用GLIB中的数据类型外，还单独定
义了一些数据类型，用来表示属性值。
值得注意的有：
l GST_TYPE_INT_RANGE:范围值
l GST_TYPE_LIST:包含任
何基本类型都可以
l GST_TYPE_ARRAY:只能
包含相同的类型
5. Caps的用处
Caps实际的用处很多，其实就是
一个寻找匹配pad或element之用。
Caps中有一项描述媒体信息的，
叫metadata。如何从caps中获取条目呢？
caps中存的是structure条 目，一个structure代表一种能力
gst_caps_get_structure/size
根据条目多少和属性，caps可分为：
l 简单caps：只含一条structure
l 固定caps：含一条structure，并且属性值没有range之类可变化的
l 任意caps和空caps是两种特殊cap
6. 创建过滤器使用的caps
刚才讲的全是从单元中获取caps，都是已经弄好了的。那么如果想动态创建caps该如何做呢？
l gst_caps_new_simple：创建simple的
l xx_full：创建n个structure的caps
这还只是创建pad，要把src和dst通过过滤单元链接起来，用
gst_element_link_filtered,内部会根据过滤pad自动创建一个capsfilter。
所以关闭链接的时候，需要把src和dst分别从capsfilter中关闭链接。而非简单
的关闭源和目标
7. 幽灵pad
有啥用？其实就是创建一个代理pad吧。
为啥要有个这个东西？因为bin本身是没有pad的。所以你就没办法把两个bin链接起来。
这个时候，可以用bin中的一个单元的pad构造一个代理pad，这样bin就有一个代理pad了。这个pad实际指向被代理的那个单元的pad。
3.7 缓冲与事件
数据流动是以缓冲传递来实际工作的，所以buffer比较在重要。
events和message不太一样，这个events实际就是命令，而且在
管道中流动。这么说的话，buffer对应的就是数据。
从命名习惯上来说，buffer更应该看成是一种容器，里边含data和events。
1. Buffer
GstBuffer有以下成员：
l 数据内存指针
l 缓冲大小
l 时间戳
l 用者计数（与引用计数对应）
l 标识
2. Events
事件是一种控制数据，能够在管道中上下流动。
一般来说，上游的控制命令可能是真的在控制什么，来自下游的events可
能大多数是些状态通知之类的。？原文是这么说的。
应用程序自己能发送控制？例如seek命令。
恩，确实应该有地方可以发送控制命令。典型的就是seek。用户也需要一
个地方能做这个工作。
看来都是通过events方式来做到控制的。
l gst_events_new_xxx
l gst_element_send_event
先创建一个命令，然后发出去….
四 基本例子
这部分对应第10章，不打算介绍了。做到能看懂代码为准。
或者自己可以想想该怎么写一个这样的例子，能解释清楚里边的API调用次序和关系等。
看明白了，看来要使用一个gst还是相对比较容易的。但是要开发一个插
件，可能难度就大很多了。尤其是里边的Buffer，事件之类的东西。争取2周搞定。
五 高级部分
5.1 查询与Seek
查询主要是获得进度信息（播放电影的时候那个进度条位置）。
seek与查询类似，seek的完成通过event方式来发送控制命令。
1. GST中的查询
GST为查询提供了丰富的接口，例
如当前时间戳，当前读取帧数等信息，都可以查询到。
questions:在哪儿查？查哪个单元，怎么查？
Answer：估计是查pipe。 调用gst_element_query
内部处理是先将该query发到sink单元，然后向上找看哪个单元能够处理，处理完了再把结果返回给调用程序。一般demuxer能够处理。
2. Seek
处理逻辑与查询类似。针对seek请求，单独可以构造一个gst_event_new_seek出来。
一个seek请求包含很多参数，这里不详述了。
有几个可以猜想到：seek的位置，seek多少等。
有一个标识关于是否刷新内部buffer的似乎很重要。
当处于PAUSED和PLAYING状态的时候，需要这个FLUSH标示。因为seek完了后，会回到以前的状态。
你可以等待seek真正完成，用：
l gst_element_get_state
l 或者等到ASYNC_DONE消息
另外，只能在PLAYING状态下设置无FLUSH标示。seek命令的完成可能是在另外一个线程来做的。内部处理逻辑如下：
l 先pause，如果开始是playing状态的话，位置信息将被重置
l 中间单元将重新位置处开始处理，直到sink单元收到数据，如果之前是play状态，则seek完成后也是play状态
5.2 元数据信息
MetaData应该是描述媒体文
件信息之用的。gst将MD分为两类：
l 标签信息（除媒体视音频格式之外的其他信息，例如属于哪个专辑，什么流派之类的），这类信息
由GstTag系统完成
l 视音频格式信息，这个由pad完成
1. Tag信息读取
这个是通过管道的bus来读取的。可以监听GST_MESSAGE_TAG来完成。
2. Tag写入
使用GstTagSetter来完成，而且该单元必须支持tag设置。
奇怪，怎么设置？源一般按普通文件打开的，没法设置啊。
所以必须先从管道中找到那些能设置的。通过：
l gst_bin_iterate_all_by_interface(GST_TYPE_TAG_SETTER)，
l 然后调用gst_tag_setter_add等函数。
看了下manual，Tagsetter是
一个接口，必须有类实现这个接口就可以了。
5.3 接口组合
接口类定义了一个实现单元应该支持的功能。
1. URI接口
其实就是定义一个支持通用路径的接口。
例如本地文件用file:////,网页文件用http://等
怎么获得一个支持特定URI地址的单元呢？
l gst_element_make_from_uri，可以指定SRC或DST
创建一个支持特定URI地址的单元。
2. MIXER接口
支持对硬件或软件音量的统一管理。一般那些直接和声卡硬件打交道的单元用实现这个接口。
有哪些功能呢？比如静音，调整左右声道等功能。
一般不要在播放中使用这种接口来控制音量，相反，应该使用sink单元的音量属性来控制。
也是啊，一般控制本地程序即可，不用去调节全局声卡的音量呀。
3. Tuner接口
用于调整多输入输出设备的，可能还是和硬件关系比较紧密。
4. 色彩平衡接口
用来调节亮度，对比度等内容的。
5. 属性探测接口
主要用途是来自动探测硬件设备的。
6. X重叠接口
X意味X-Window，主要是绘图用。
5.4 时钟
GST中使用时间的原因是：
l 有些单元提供了时钟，要是管道中没有时钟的话，就会用默认的系统时钟
l 有些单元根据时钟干活（clock slaves）
GST中时间有好几种：
l 时钟时间，就是普通时间，一直增加的
l 基础时间：其实就是开始时间
l 运行时间：播放的时间，包括重播，回播种种之和
l 流时间：这个可能真的是一个单次播放的时间，例如一次重播，一次完整播放等
1. 时钟提供者
为何存在这个？因为有些视音频文件必须按照媒体自己的时间来走，而不是系统的时间频率。
2. 时钟使用者
管道会有一个时钟，然后给其他时钟使用者使用，时钟使用者应该确保回放的东西跟得上时钟。
一般是要等待一个时间，用gst_clock_id_wait函数，或者丢几帧数据。
加载中，请稍候......
加载中…
喜欢