GStreamer学习笔记（八）——基础教程7：多线程和Pad可用性

原文：Basic tutorial 7: Multithreading and Pad Availability (gstreamer.freedesktop.org)

目标

GStreamer自动处理多线程，但是，在某些情况下，您可能需要手动解耦线程。本教程展示了如何做到这一点，此外还完成了关于Pad可用性的介绍。更准确地说，这份文档解释了:

• 如何为pipeline的某些部分创建新的执行线程

• Pad的可用性是什么

• 如何复制流

概述

多线程

GStreamer是一个多线程框架。这意味着，在内部，它根据需要创建和销毁线程，例如，从应用程序线程解耦流。此外，插件也可以自由地为自己的处理创建线程，例如，视频解码器可以创建4个线程来充分利用4核CPU。

此外，当构建管道时，应用程序可以显式指定分支(pipeline的一部分)在不同的线程上运行(例如，让音频和视频解码器同时执行)。

这是使用queue元素完成的，其工作方式如下。sink pad只是对数据进行入队并返回控制。在另一个线程上，数据被从队列中取出并向下推送。该元素还用于缓冲，稍后将在流媒体教程中看到。可以通过属性控制队列的大小。

示例pipeline

source是一个合成音频信号(一个连续的音调)，使用tee元素进行分割(它把通过的sink pad接收的一切通过source pad发送出去)。然后一个分支将信号发送到声卡，另一个分支呈现波形的视频并将其发送到屏幕上。

如图所示，队列创建一个新线程，因此该pipeline在3个线程中运行。具有多个sink的pipel通常需要是多线程的，因为要同步，sink通常会阻塞执行，直到所有其他sink准备好，如果只有一个线程，它们就无法准备好，被第一个sink阻塞。

请求Pad

在基础教程3中，我们看到一个元素(uridecodebin)一开始没有pad，等到数据开始流动和元素了解到媒体时出现了pad。这些被称为“sometimes pad”，与经常可用的"always pad”形成对比。

第三种类型的pad是Request pad，它是按需创建的。典型的例子是tee元素，它有一个sink pad，没有初始source pad:它们需要被请求，然后tee添加它们。通过这种方式，输入流可以被复制任意次数。缺点是使用Request Pads链接元素不像链接Always Pads那样自动，本示例的演练将显示这一点。

此外，要在PLAYING或PAUSED状态下请求(或释放)pad，您需要采取额外的注意事项(pad阻塞)，本教程不会对此进行描述。但是，请求(或释放)处于NULL或READY状态的pad是安全的。

话不多说，让我们来看看代码。

简单的多线程示例

#include <gst/gst.h>

int
main (int argc, char *argv[])
{
  GstElement *pipeline, *audio_source, *tee, *audio_queue, *audio_convert,
      *audio_resampl