gstreamer是linux上面的一个音视频框架,具有结构清晰,面向对象,可扩展性高,内存传递高效等优点。gst优点来自于其设计的结构分明的框架,面向对象是通过继承Glib来实现的,可扩展性是基于插件机制来达到的,内存传递高效是基于其调度模式实现。通过本专题希望能够达到对gstreamer的基本概念有了解,知道如何基于gstreamer创建一个应用,理解Gstreamer插件的工作原理,了解各个插件间如何协作以及调试问题的基本方法。
首先从宏观上介绍下gstreamer的基本概念,然后看看应用是如何基于这些基本概念构造一个实现音视频播放的应用。宏观上有了了解之后,在深入了解gstreamer的工作原理之前,先了解一下 使gstreamer具有强大功能的两大基石Glib和插件。然后深入了解Gstramer中最重要也是最强大的pipeline-playbin3,基于playbin3可以了解到插件的协作机制。另外单独介绍gst中调度模式, 状态变迁以及音视频同步机制。 最后了解gst的代码目录结构以及调试方法,以及目前解决的一些问题。
1.1 element
元件 就把元件当成是gstreamer某个功能模块的抽象,是组成其他部分,创建不同媒体应用的基本构件。对数据的处理都是封装成一个个元件,比如读取文件数据是个元件,读网络流是另外一个元件,解封装,解码等都是一个元件。 每个元件都有对应的名称,根据名字 可以用api从元件工厂中去创建element。
element的类型:
- src类型: 从文件或者网络中读取数据 然后将数据传递给下游处理。
- 既有src 又有sink pad的类型,src 和sink都可能不止一个:demux,filter,decode等 。
- sink类型:只有sink pad的元件 这样的元件接收其他元件的数据 并输出到具体的设备上。
1.2 bin/pipeline
bin 和pipelines 也都是属于element,一般来说,bin是将不同功能的element 组合在一起 进行统一管理。 bin可以统一向bin中的元素进行消息发送,状态变化等。 pipeline是更高一级的bin,可以将不同的bin放到一个pipeline中,控制pipeline的状态,可以使的得数据在pipeline中进行流动。
1.3 pads
pad是用在于element之间的连接,是依附于element之上的,element 之间的数据流动和事件的传递是通过pad的进行的。pad另一个重要作用是限制流经两个element直接的数据。
pad的类型(sometime、always、on demands)
sometime的意思是不一定一直存在, 需要某些触发条件触发。比如解析到了某些数据,那么就触发消息上来。
gst_bin_add_many (GST_BIN (pipeline), source, demux, NULL);
gst_element_link_pads (source, "src", demux, "sink");
/* listen for newly created pads */
g_signal_connect (demux, "pad-added", G_CALLBACK (cb_new_pad), NULL);
1.always
这种pad最简单 就是在创建element的时候就有了 也是一直存在的
2.request
在某些elemnt的需要的情况下才会去调用的,可以通过gst_element_get_request_pad()方法可以从一个元件中得到一个衬垫
3. ghost pad
精灵pad, 通常用在bin上,如果bin自己没有pad, 可以利用包含的element的pad 作为自己的pad可以通过函数gst_ghost_pad_new ()可以创建一个ghostpad。
sink = gst_element_factory_make ("fakesink", "sink");
bin = gst_bin_new ("mybin");
gst_bin_add (GST_BIN (bin), sink);
/* add ghostpad */
pad = gst_element_get_pad (sink, "sink"); // 从创建的sink element 这边获取到一个sink 的pad
gst_element_add_pad (bin, gst_ghost_pad_new ("sink", pad)); // 依据这个pad来创建一个ghostpad 并加这个pad加入到创建好的bin 当中
gst_object_unref (GST_OBJECT (pad));