gst将实际应用的每个功能模块抽象成元件，元件之间的连接是通过绑定在上面的pad来实现的。所以需要了解下具体数据是如何从一个元件流向另一个元件的。数据的流向可以从上游流向下游， 也可以下游去上游取。这两种方式分别对应的就是push mode 和pull mode。
6.1 push模式（以视频解码显示为例）
大部分情况下都是工作在push mode。 所以重点介绍下 push mode，所谓的流向 实际上将上游元件的buffer指针传入到 下游元件的特定 函数， 这个函数就是 元件pad 上面的一个chain函数。
任意工作在push模式的两个元件，必须要有的步骤分别是
1、调用gst_pad_link_full (GstPad * srcpad, GstPad * sinkpad, GstPadLinkCheck flags)
将当前srcpad 和下游的sink pad连接起来 这个函数就将srcpad的peer指定为 sinkpad，将sinkpad的peer指定为srcpad。
2、调用 gst_pad_set_chain_function 设置下游element sink pad 的chain函数
3、在当前元件的chain（或者其他）函数中调用gst_pad_push 将当前元件中处理好的buffer push到下游元件。gst_pad_push 函数是调用的当前srcpad的peer 即下游 sinkpad的chain函数。这样就完成两个element间的push工作，这样从一个elemnt push到另一个，就可以完成整个解码显示的过程。
以hevc解码为例（multiqueue ----> decoder ----> video_sink）
loop中mutiqueue 将上游parse的buffer 调用gst_pad_push push到下游decoder上，即调用decoder的chain函数。从之前GLIB那边知道，GstFFMpegVidDec 是继承的是gstvideodecoder，gstvideodecoder只是实现了接口，具体是调用子类的实现 。所以调用到了gstvideodecoder的chain chain里面 调用 子类的decoder_class->handle_frame 而在gstavvidec 中 调用的是gst_ffmpegviddec_handle_frame，handle_frame 则调用的是ffmpeg的接口avcodec_decode_video2 来进行解码 这一接口就完成parse hal操作，利用硬解将buffer解码完成， 完成之后调用 gst_video_decoder_finish_frame将解码后的buffer push到下游 video-sink。
从playbin那知道，这个时候的video-sink 实际上是kms-sink
同样gstkmssink 继承至gstbasesink。 gstbasesink定义了一堆有关显示的接口，由子类 gstkmssink来实现。在gstbasesink的chain函数 依据音频的时间 来进行同步，同步后调用子类gstkmssink的render函数 将视频显示到设备上。其中kmsink 调用的是比较底层的接口 drmModeSetPlane，传入的是需要的plan id， 设备的id ，buffer 的id 以及buffer 的起始坐标和宽高， 目标设备的起始坐标和宽高。
6.2 pull模式（以数据的读取 解封装为例）
pull模式的前提是 当前元件的sink pad 设置了active 的函数，并且上游元件实现了gst_XXX__getrange函数
1、 如何确认某个element是工作在pull模式 还是 push 模式
首先在上层应用改变playbin的状态 ，changeState会根据sink到source的顺序改变bin中元件的状态， 当元件的状态从READY--->PAUSE 改变的时候，gst core的gstbin中 会将调用bin中每个element pad 的 active function，以便于准备数据的流动。 一个组件的pad active 顺序是从source pad 到sink pad。这个是为了保证sinkpad 准备好能够接收数据的时候， sourcepad已经能够将数据推送到下游。pull pads 的方式 是 当前元件的sink pad 调用gst_pad_pull_range()来从上游的srcpad 请求数据。sink pad 是决定当前元件是工作在 pull 还是push模式， 所以要先看当前element的sink pad的 active函数， 如果当前的sink pad没有设置active函数，那么sink pad的active就采用默认的active，这种情况下就是工作在push模式下。如果sink pad 设置了active的函数 在active的函数里面 的任务是:
生成一个调度模式的查询事件， 将这一查询事件push到peer pad（即 上游元件的srcpad），获取查询之后放回的mode如果是pull mode 将sink pad active在 pull的模式 即调用 sink_activate_mode 函数
2、 工作在pull模式的数据是怎么流动
如果是pull mode的话，起一个task，里面会调用上游的pull_range函数获取数据，获取数据后就进行demux处理，处理之后调用gst_pad_push push到下游元件中。
3、以typefind element为例
gsttypefindelement.c中在gst_type_find_element_activate_sink函数中调用gst_pad_peer_query (pad, query)这个会调用peer 也就是gstbasesrc 的 gst_base_src_default_query (GstBaseSrc * src, GstQuery * query)。在这里面会判断当前的元件是否支持随机访问 支持的话，那么返回MODE_PULL.gst_query_add_scheduling_mode (query, GST_PAD_MODE_PULL);
返回MODE_PULL到activate sink。activate sink 调用 起一个task 来pull数据进行处理，pull也就是 调用的peer即srcpad的getrange GST_PAD_GETRANGEFUNC (peer)。srcpad的getrange 在gstbasesrc中进行设置
gst_pad_set_getrange_function (pad, gst_base_src_getrange)。gst_base_src_getrange这里面就调用到gstfilesrc的接口来进行读取文件
综上所述 工作在pull模式需要具备的条件：
1、
对于当前的元件而言：要实现sink activate的函数
gst_pad_set_activate_function (demux->common.sinkpad,
GST_DEBUG_FUNCPTR (gst_matroska_demux_sink_activate));
sink activate的任务是查询上游的srcpad 支不支持 pull 模式
2、
在上游元件端 需要对下游发上来的query进行处理 并返回查询的结果。
然后 设置srcpad 的getrange_function 供sinkpad 调用
gst_pad_set_getrange_function (typefind->src,
GST_DEBUG_FUNCPTR (gst_type_find_element_getrange));
3、当前元件在自己的chain函数 或者 loop 中调用gst_pad_pull_range 来读取数据