Gstreamer架构分析

Gstreamer架构分析

1Gstreamer架构图:

AGstreamer是一个提供媒体处理能力的强大的库。

B.通过gstreamer,应用程序可以通过简单的接口处理媒体,不必理会具体的媒体处理过程。

 

Gsteamer包含以下包:

--gstreamerthe core package//核心库,支撑整个框架,具体做事如解析文件、解码、输出。交给‘小弟’plugin去做。

--gst-plugins-base:包含基本element

--gst-plugins-goodLGPL的高质量element

--gst-plugins-ugly:高质量的element,可能有法律问题。

--其他

2Gstreamer基本概念

Elements

--  Gstreamer中最基本的元件,他的类型可能是sourcesfiltersmuxersdemuxerscodecs或者sinks

Pads

--  element的输出或者输入。

Bins

--  包含一组element的容器。

Pipelines

--  特殊的bin,包含一组能完成某个任务需要的element,可以允许它包含的element可执行。

     (一般是将多个elements加入到pipeline里面)

Buses

--  处理pipeline线程消息,并通知应用程序的系统。

--  每条pipeline缺省都有一个bus

 

他们之间的关系,大致如下图:

(个人的理解)

Gstreamer编程,首先创建基本元件,pipelinefilesrcdecoderalsasink等,然后把这些元件加入到pipeline中,并链接起来,最后改变pipeline的状态,就可以启动对媒体数据的处理。

在不知道文件类型的情况下,也可以动态创建元件,调用typefind函数,他能找出能够解析它的插件,然后连接到上一元件的后面,以此类推,根据前面不同的类型,在后面选择不同的插件连接到后面。最后同样把这些元件加入到一个pipeline中,并链接起来,这时改变这个pileline的状态就可以启动对数据的处理。

3 构建Gstreamer

3.1 初始化

GST库必须先初始化,调用gst_init()

3.2 单元elements

GstElement是最重要的对 象。一些高级对象也是从它派生出来的。有好几种类型的elements,必须分清楚了。

1.源单元

source单元是数据的产生方, 对应一个源pad。一般画在右边。

源单元只能生产数据,不能接收数据

2.中间单元

中间单元包括过滤器,转换器,复用器,解复用器,编解码器等。

它有多个源pad,对应多个目标pad

3.目标单元

只能接受数据。

4.创建和使用单元

通过factory_makegst_object_unref来创建及释放单元。make需要两个参数,一个是工厂名,一个是单元名。工厂名实际就是插件名,所以需要先加载插件上来,才能创建对应的单元。

单元继承所有Gobject的属性,所以可以当做Gobject来处理。

单元有属性,单元还能触发信号,所以必须关注这些。

作为工厂,其功能还不仅限于创建单元,一个工厂有属性,它知道自己能创建怎样的单元。

其实就是这个插件知道自己能创建怎样的单元。可能需要看了插件编写才真正知道。

5.链接单元

单元必须链接起来,才能协同工作。

源单元à中间单元à目标单元

l        必须先加到管道后才能link起来。

l        不在同一bin中的不能link

6.单元状态

单元链接好后,啥事也不会发生,除非设置单元状态。单元一共有四种状态:

l        GST_STATE_NULL:默认 状态,内部会释放单元的所有资源,其实就是初始状态。

l        XXX_READY:就绪状态,分配 资源,打开设备。但是流不会打开,所以此时流信息都是零。如果之前打开了流,在这状态中将会被关闭,流信息都会被重设。

l        XXX_PAUSED:已经打开了 流,但是暂时不处理它。这个时候可以去修改例如seek位置等流信息。时间轴停止

l        XXX_PLAYING:时间轴运 行。设置为这个状态后,整个流程就开始启动了。内部会将消息发送从管道所在的线程转移到应用程序线程。(?)

通过set_state函数设置状态,GST会平滑设置,例如从PLAY设置为NULL,将平滑设置READYPAUSED

3.4 Bins

Bin不仅是一个单元的集合,更是 集成了对内部单元的管理。管道是一种特殊的bin,实际要播放一个视音频就得用到管道。管道能独立在后台运行。

1.创建Bin

Binelement派生而来,所以创建 单元的函数均可创建Bin,但一般用两个更方便的函数:

l        gst_bin_new

l        gst_pipeline_new

Bin是一个集合,需要将单元加入 进去,也可以删除。

l        gst_bin_add,gst_bin_remove

注意,一旦加入到Bin,单元的所有者就变为Bin了,所以删除Bin的话,内部的单元也会相应减少引用。

2. 定制化Bin

还是得看插件编程指南才能真正理解。

3.5 Bus

1. 总论

Bus的好处是可以把pipeline所在的线程的消息 路由到应用程序指定的那个Context中去。

bus上要加入监控回调函数。通过

l        gst_bus_add_watch/gst_bus_add_signal_watch

l        要从bus中取消息,得调用gst_bus_pop/peek/pop

注意,Bus发出的消息是GstMessage结构,值得解释。

Bus含一个队列,每次post一个消息就加到队列里,然后出发maincontextwakeup。 这样就完成了将消息路由到maincontext去了。因为maincontext等待的有这个bus队列。

有没有办法不用默认context呢?有一个函数将message转换为signalemit

l        gst_bus_async_signal_func

这里要区分下messagesignalsignalGobject系统提供的,messageGST提供的。message的处理是异步的,而signal的处理是同步的。

如果你不想写很多switch来区别message的话,那么另外一种办法就是注册对应的signal到系统。另外,如果不使 用mainloop的话,异步消息-信号不会发出去。

bus的消息分为异步和同步两类。

l        异步信号是通过加入到mainloop中的Gsource来触发的,所以必须有mainloop再运行才可

l        同步信号必须先注册一个同步信号处理函数才可。

需要自己设置一个同步信号处理函数,在那里触发另外一个context,并且调用上面这个函 数发送signal

2.  message类型

描述一个message有以下:

l        Message的来源:记录是从哪个 单元发出来的

l        类型:

l        时间戳

比较重要的是类型信息:有以下几类类型

l        error,warning,info等 信息:需要调用对应API进行解析

l        EOS:文件结尾,需要重设管道状态 等

l        Tag:标签信息(其实就是媒体信 息,比如长度,采样率等)State变化:

l        缓存信息:调用gst_bus_get_structure来解析缓存信息

l        单元信息:某些单元会发送特殊的信息应用程序自己的信息

3.6 Pads和属性

Pads很关键,代表了单元的出入 口。标示Pads特性的有两个:

l        方向,从单元内角度看,sink收数据,source发数据

l        可用性(availability

方向好说,只有sinksource两种,可用性是一个新概念。主要代表这个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,根据源padcaps来从单元中找一个相容的。

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实际的用处很多,其实就是 一个寻找匹配padelement之用。

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:创建nstructurecaps

这还只是创建pad,要把srcdst通过过滤单元链接起来,用

gst_element_link_filtered,内部会根据过滤pad自动创建一个capsfilter

所以关闭链接的时候,需要把srcdst分别从capsfilter中关闭链接。而非简单 的关闭源和目标

7. 幽灵pad

有啥用?其实就是创建一个代理pad吧。

为啥要有个这个东西?因为bin本身是没有pad的。所以你就没办法把两个bin链接起来。

这个时候,可以用bin中的一个单元的pad构造一个代理pad,这样bin就有一个代理pad了。这个pad实际指向被代理的那个单元的pad

 

3.7 缓冲与事件

数据流动是以缓冲传递来实际工作的,所以buffer比较在重要。

eventsmessage不太一样,这个events实际就是命令,而且在 管道中流动。这么说的话,buffer对应的就是数据。

从命名习惯上来说,buffer更应该看成是一种容器,里边含dataevents

1. Buffer

GstBuffer有以下成员:

l        数据内存指针

l        缓冲大小

l        时间戳

l        用者计数(与引用计数对应)

l        标识

2. Events

事件是一种控制数据,能够在管道中上下流动。

一般来说,上游的控制命令可能是真的在控制什么,来自下游的events可 能大多数是些状态通知之类的。?原文是这么说的。

应用程序自己能发送控制?例如seek命令。

恩,确实应该有地方可以发送控制命令。典型的就是seek。用户也需要一个地方能做这个工作。

看来都是通过events方式来做到控制的。

l        gst_events_new_xxx

l        gst_element_send_event

先创建一个命令,然后发出去….

 

4. 小结:

        Gstreamercore只负责把各个部分联系起来,组成一个可以运行工作的整体,真正做事的是元件(elements)。谈到元件不得不提到插件(plugin),Gstreamer有很多类插件,plugin-baseplugin-good等,插件中包含很多的元件,元件就是根据插件中的某一个元件动态创建的,完成具体某一项功能,如H264解码(它只负责接收特定格式的数据,然后解码,最后输出特定格式的数据)。

你可能感兴趣的:(其他类unix系统相关,signal,structure,events,buffer,工作,dst)