Gstreamer工作原理分析

1.         Abstract

主要讲的是gstreamer的工作原理，包括gst-launch的分析和playbin的分析，以及数据的流动分析。

2.         Introduction

先介绍一些术语，然后介绍了插件的工作原理，后面接着介绍了gst-launch,playbin,decodebin,typefind,数据流动.

3.         原理分析

3.1   术语介绍.

3.1.1      元素

代码里面的类型是GstElement,可以理解为gstreamer里面的基类。

3.1.2     一些特别的元素。

         Source:可以理解为源头，也就是数据流的起始地，就像长江的发源地是沱沱河一样。

        

Sink:就是这个数据流最终要流向的地方，就像长江最终要流向东海一样。

         

Filter:过滤器，就像是筛子一样滤掉我们不感兴趣的东西，流下我们想要的东西，或者从代码上来说就是拦截下数据，对这个数据做一定的修改或者其它动作，当然你什么也不做也是可以的，然后再把数据传出去：

         

Pipeline:典型的pipeline是这样的：

更复杂一点的：

Bin:有点像pipeline，它们的区别就是pipeline肯定是一个bin，但bin不一定是pipeline，它就像一个盒子，里面放了什么东西你可以不关心。

Ghostpad:文档上说ghost pad就像linux里面的link文件，我的理解是在一个盒子上开一个口，这样里就可以访问这个盒子了。

 

1.1   插件的工作原理。

         如下图所示，这个所有的基于插件的程序的工作原理类似，本质上都是通过读取动态库实现的，只需要每个动态库都实现某一个特定的接口就可以了，比如XX_init等，这里就是plugin_init。

里面会有个像注册表一样的数据结构会存储所有的插件的信息。

1.1   Gst-launch的工作逻辑

 

它的工作原理就是根据 ！号来划分输入的字符串，然后为每个元素构建一个element，最后建立一个pipeline把这些元素加入，最后通过setstate来启动整个数据循环。

 

1.1   动态pipeline的创建原理

我们经常需要创建动态的pipeline，因为我们不知道源头是什么格式的，这时候需要这么做：

比如demuxer，

pipeline =gst_pipeline_new ("my_pipeline");

//创建pipeline

source =gst_element_factory_make ("filesrc", "source");

//创建src

g_object_set(source, "location", argv[1], NULL);

//设置输入文件路径

demux =gst_element_factory_make ("oggdemux", "demuxer");

//创建demux元素

gst_bin_add_many(GST_BIN (pipeline), source, demux, NULL);

//把这两个元素加入到pipeline里面

gst_element_link_pads(source, "src", demux, "sink");

//把这两个元素连接起来

g_signal_connect(demux, "pad-added", G_CALLBACK (cb_new_pad), NULL);

//这里是关键，demux会创建出一个pad，于是发出信号，等待我们设定的函数cb_new_pad.

gst_element_set_state(GST_ELEMENT (pipeline), GST_STATE_PLAYING);

//启动整个数据流循环

loop =g_main_loop_new (NULL, FALSE);

g_main_loop_run(loop);

//启动gloop事件循环

static void

cb_new_pad(GstElement *element,

          GstPad     *pad,

          gpointer    data)

{

  gchar *name;

  name = gst_pad_get_name (pad);

  g_print ("A new pad %s wascreated\n", name);

  g_free (name);

  /* here, you wouldsetup a new pad link for the newly created pad */

…...

}

在这里就可以根据不同pad来连接不同的后面的element,比如：

gst_element_link_pads(pad, "src", fakesink, "sink");

而如何发现源数据的类型则是这样的：

typefind =gst_element_factory_make ("typefind", "typefinder");

  g_signal_connect (typefind,"have-type", G_CALLBACK (cb_typefound), loop);

每当typefine插件查出类型的时候就会发出这个信号。

“Once a media type hasbeen detected, you can plug an element (e.g. a demuxer or decoder) to thesource pad of the typefind element, and decoding of the media stream will startright after.”

总结:从上面这些例子可以看出，它的工作过程是这样的：

首先连接能够连接的原素，比如前端src->decodebin，然后后端连接converter->resampler->volume->

audiosink。

通过decodebin的信号，根据源类型创建特定的srcpad，再把这个pad连接到后端（后端可以创建一个ghost pad以方便使用）这样一个pipeline就建好了

 

 

 

 

 

1.2   Decodebin的工作原理

  3.4节已经用文字介绍了decodebin的工作原理，下面的图是讲它的内部实现的：

1.1   Typefind的实现原理

这里是讲程序是如何查找出对应文件应该选用什么解码器之类的，可以简单理解为source识别。

1.1   Setup element

这里主要讲的是如何把这些播放一个source所需要的element连接起来的：

1.1   Playbin的工作原理

         有了上面几个步骤就可以很容易理解playbin的工作原理，不过细节依然非常的复杂，我只是画了框架图：

1.1   数据流动

下面讲的是里面最复杂的数据流动的分析，我主要分析了src的流动和sink的流动，因为中间的数据流动太多，比如解码器，filter等等，实在没空，但是我想有这两元素的分析，其它的元素就很容易了：

1.1   总结

.时间有限，我只能分析这些框架了，估计看懂这几个图也不容易，

两个关键的函数是change_state,这是一个经常被重载的函数，基本上元素的初始化，状态的改变都会在这里面会被处理， 另外一个非常关键的chaingfunc这个函数是开启数据流动的关键函数，通常src调用chainfunc函数，在这个函数里面会取出peer pad 的chainfunc，然后调用src对应的sink的chainfunc，另外一个让我迷惑了很久的是到sink的数据是如何流动的，最后分析的 结果是它使用了一个环行缓冲，并且使用了线程同步操作来实现生产者消费者 的模式以加快数据的传递，所以数据的最终传递是通过发出p、v操作来实现的，里面先把数据取出来调用memcpy来copy到环行缓冲，然后发出v操作，对应的消费者被唤醒调用sink插件的write操作把数据写到设备里面去，这里面还有几块我没有分析的，比如时间戳的处理，各种元素之间的延迟的协商，以及音频视频之间的同步播放等，这里面涉及很多多线程问题，如果要分析估计得花很多的时间。

 

 

2.         reference

[1] http://gstreamer.freedesktop.org/documentation/

 

 

 

 

 

 

 

补充：

＃playbin的工作流程

1,创建source。

2，创建decodebin。

3，为decodebin添加typefind。

4，在向bin添加元素的时候都会发出element-added的信号。

5，向decodebin添加fakesink。

6，把decodebin加入到playbin.

7, 等待typefind元素发出的have-type信号，并调用回调函数，注意这里的信号实际是只包含了caps信息，而后，根据注册表里面的每个factory取出其提供的caps与typefind提供的caps取交集，如果有交集则加入到一个list表中(find_compatibles)。

8，取出list里面的元素来连接，如果找到一个就结束，找到后把这个元素与src元素连接起来，递归的进行这个元素本身的sinkpad的连接，直到收到了no_more_pads的消息。

9,decodebin收到no_more_pads消息后也会发出同样的消息，其余处理逻辑请看文档工作原理》.

 

 

 

注意:close_pad_link

1,通常每一个element在被创建的时候都会添加自己的pad，所以都会发出pad－added的信号。

2,close_link(GstElement * element, GstDecodeBin * decode_bin)

try_to_link_1(GstDecodeBin * decode_bin, GstElement * srcelement, GstPad * pad, GList *factories):这个函数的意思是从这个factories里面取出某个能够连接到pad的元素，和srcelement连接起来,连接起来后还要为这个刚连接起来的元素寻找到它的归属，也就是为它寻找它的sink,调用的函数是close_link,当从这个函数返回的时候，或则它的sinkpad已经被装上或则如果是动态的则已经装上了信号处理器等待sinkpad被动态装上,于是gst_element_set_state(element, GST_STATE_PAUSED);当这个函数执行完后，所有的需要安装sink的元素都已经好了，这个函数会发出pad-added信号，而这个信号的处理函数是new_pad,在这个函数里面会调用close_pad_link根据pad和caps寻找适合这个pad的sinkpad,所有实际是从这个函数返回后，几乎所有的setup工作都已经over了,可以理解为将要从typefind元素的have-type信号的信号处理函数type_fount返回了，当然之前还会收到no_more_pads的信号执行处理函数no_more_pads,于是decodebin发出了no_more_pads的信号，于是playbin会根据这个信号执行处理函数group_commit.

3,close_pad_link(GstElement * element, GstPad * pad, GstCaps * caps, GstDecodeBin * decode_bin,gboolean more):这个函数是根据pad和caps为它寻找到一个可以与之连接的一个链表，或则如果这个caps代表raw数据则创建并添加一个ghostpad到decodebin里面去。

4，find_compatibles(GstDecodeBin * decode_bin, const GstCaps * caps):这个函数的意思是根据这个caps从注册表里面找出和它有交集的GstElementFactory，并加入到list中返回。

5,close_link (GstElement * element, GstDecodeBin* decode_bin):这个函数的意思是为element添加sink，如果它的src pad是动态的，则调用dynamic_add来添加信号处理函数,等

待它的动态的pad被添加上,如果不是动态的就调用close_pad_link来从注册表里面选择合适的sinkpad来加入。

 

 

 

 

TYPE_FIND_REGISTER(plugin, "video/mp4", GST_RANK_PRIMARY, m4v_type_find,

      mp4_exts, M4V_CAPS, NULL, NULL);

行；需要移掉gstdecodebin.c和gstdecodebin2.c里面的函数find_compatibles里面的to_try= g_list_reverse (to_try)