Basic tutorial 8: Short-cutting the pipeline

Example of appsink/appsrc.

目标

GStreamer构造的pipeline不需要完全封闭,有几种方式允许用户在任意时间向pipeline注入或提取数据。本教程将展示:

  • 如何将外部数据注入通用的GStreamer pipeline。

  • 如何从通用的GStreamer pipeline中提取数据。

  • 如何访问和操作从GStreamer pipeline中取出的数据。

Playback tutorial 3: Short-cutting the pipeline中使用基于playbin的pipeline以另外一种方式实现了相同的目标。

介绍

应用程序可以通过几种方式与流经GStreamer pipeline的数据交互。本教程将展示最简单的一种,因为使用了为这一目的所设计的element:appsinkappsrc

Buffer

数据以称为buffers(缓冲区)的块的形式通过GStreamer管道传输。由于本例生产和消费数据,我们有必要了解GstBuffer。

Source pads生产buffer,而sink pads消费buffer,GStreamer接受这些buffer并将它们从一个element传递到另一个element。

一个buffer仅代表一个数据单元,用户不应该假设:

  • 所有的buffers拥有相同的大小

  • 一个buffer进入一个element就会有一个buffer从这个element出来

Elements可以随意处理它们接收到的buffer。

GstBuffer可能包含不止一个世纪的内存缓冲区,实际的内存缓冲区是使用GstMemory对象抽象出来的,一个GstBuffer可以包含多个GstMemory对象。

每个buffer都附有时间戳和持续时间,描述了buffer内容应该被解码、渲染或播放的时刻。事实上时间戳是一个非常复杂而微妙的主题但目前这个简单的解释已经足够了。

举例来说,一个filesrc(可以读取文件的GStreamer element)插件生产的buffer具有ANY类型的caps和无时间戳信息。而经过解复用(详见Basic tutorial 3: Dynamic pipelines)之后buffer将拥有一些特殊的caps,例如video/x-h264。在经过解码之后,每一个buffer都将含有一帧具有原始caps的视频帧,例如video/x-raw-yuv以及非常准确的时间戳,标记了这一阵将被播放的时间。

教程

本教程是Basic tutorial 7: Multithreading and Pad Availability的拓展,主要包含两个方面:

  • audiotesetsrcappsrc取代,音频数据将由appsrc产生。

  • tee插件增加了一个分支,因此流入audio sink和波形显示的数据也被复制了一份传给appsink

appsink会将信息回传到应用程序中,在本教程中仅仅是通知用户收到了新的数据,但是显然appsink可以处理更复杂的任务。

img

A crude waveform generator

basic-tutorial-8.c

工作流

例程的131-205行创建了一条Basic tutorial 7: Multithreading and Pad Availability中pipeline的拓展版本,包括实例化所有elements,自动连接所有具有Always Pads的elements,手动连接从tee中申请的Request Pads

appsrc

appsrc首要设置的属性就是它的caps,它指定了appsrc将生成的数据类型,以便GStreamer可以检查它是否能够和下游elements连接(下游elements能否处理这种数据)。caps属性值必须是GstCaps对象,GstCaps对象可以使用gst_caps_from_string()解析一个字符串对象来构建。

我们连接了appsrcneed-dataenough-data信号,它们将在appsrc内部队列数据不足或快满时分别被触发。本教程使用这两个信号分别启动/停止信号发生过程。

appsink

我们连接了appsinnew-sample信号,每当appsink到数据的时候就会触发这个信号。与appsrc不同,appsinkemit-signals属性的默认值为false,因此我们需要将它设置为true以便appsink能够正常发出new-sample信号。

启动pipeline,等待消息和最后的清理资源都和以前的没什么区别。下面主要讲解注册的回调函数:

need-data

appsrc的内部队列缺乏数据的时候就会触发上述回调,在这个回调函数中唯一做的事就是使用g_idle_add()注册了一个GLib空闲函数,在空闲函数中将不断向appsrc的传递数据只知道它的内部队列队满。GLib空闲函数是当它的主循环处于“空闲”状态时将被调用的方法,也就是说当前没有更高优先级的任务需要执行。调用GLib空闲函数需要用户线初始化并启动一个GMainLoop(推荐阅读GMainLoop以获得更多关于GMainLoop的信息)。

这时appsrc允许的多种方法中的一个。事实上buffer并不需要使用GLib从主线程传递给appsrc,也不一定需要使用need-dataenough-data信号来与appsrc同步(据说是最方便的)。

如前文所说,流由GStreamer的单独线程处理,在实际的应用程序开发中appsrc的数据来源总是其他线程,数据的消耗有应用程序自行管理,通常消耗数据的速度足够快因此并不特别处理appsrc的enough-data信号。

我们维护g_idle_add()返回的sourceid,稍后需要禁用它。

enough-data

这个函数当appsrc内部的队列满的时候调用,所以我们需要停止发送数据。这里我们简单地用g_source_remove()来把idle函数注销。

push-buffer

我们使用上述函数向appsrc传递数据,GLib将以自己的频率和速度调用它(调用不受用户控制),但是我们连接了enough-data信号以确保appsrc队满的时候能够停掉它。

它的第一个任务是使用gst_buffer_new_and_allocate()申请了一个给定大小的GstBuffer(在这个例子中是1024字节)。

我们计算我们生成的采样数据的数据量,把数据存在CustomData.num_samples里面,这样我们可以用GstBuffer提供的GST_BUFFER_TIMESTAMP宏来生成buffer的时间戳。

gst_util_uint64_scale()是一个实用函数,用于缩放数据,确保不会溢出。

申请的buffer内存可以使用GstBuffer提供的GST_BUFFER_DATA宏来访问,在使用过程中要注意申请内存的大小以免操作越界。

GST_BUFFER_DATA等价于gst_buffer_map (buffer, &map, GST_MAP_WRITE);。

这里跳过波形的生成部分,因为这不是本教程要讲述的内容。

一旦我们的buffer已经准备好,我们把带着使用push-buffer动作信号将这个buffer传给appsrc,然后就调用gst_buffer_unref()方法,因为我们不会再用到它了。

new-sample

最后,这个函数将在appsin接收到buffer数据的时候调用,我们使用pull-sample动作信号来获取buffer,然后向屏幕输出一个*以说明appsink成功接收到数据。我们可以使用GstBuffer提供的GST_BUFFER_DATA宏获取buffer的数据指针,使用GST_BUFFER_SIZE宏来获取buffer的数据大小。注意appsink接收到的buffer不一定和push_data函数中生成的buffer一致,因为在这个pipeline分支路径上的任何elements都能够修改经过它的buffer(但不是这个例子,本例中buffer仅经过一个tee,而tee并未改动buffer的内容)。

随着我们使用gst_buffer_unref()释放buffer,本教程也到此为止。

总结

这篇教程展示了应用程序如何:

  • 如何使用appsrc元素向pipeline插入数据。

  • 如何使用appsink元素从pipeline中检索数据。

  • 如何通过GstBuffer操作从pipeline中取出的数据。

Playback tutorial 3: Short-cutting the pipeline中使用基于playbin的pipeline以另外一种方式实现了相同的目标。

关于应用程序与GStreamer pipeline的数据交互,可以阅读GStreamer App以获得更多实用信息。

原文地址:https://gstreamer.freedesktop.org/documentation/tutorials/basic/short-cutting-the-pipeline.html#

Last updated

Was this helpful?