DeepStream 组件

DeepStream/Gstreamer 管道使用图形规范实现，方法是将 GStreamer 元素包装在图形组件中，并添加支持组件以实现图形组件与 GStreamer 管道之间的通信。本节介绍 DeepStream 图中使用的组件类型。

接口

DeepStream 扩展为某些常用类型的组件和功能提供接口（抽象基类型）。这些接口为其他组件提供了一种方式，使其可以与实现或继承自该接口的各种组件进行交互，而无需依赖实际的类型/实现。例如，NvDsInfer 组件具有一个参数 infer-model-config，其句柄类型为 INvDsInferModelConfigComponent。INvDsInferModelConfigComponent 基类型适用于表示 NN 模型的组件（模型文件、关联的配置、后处理算法）。因此，NvDsInfer 组件可以加载任何类型的模型，而无需实际依赖模型组件的具体类型，只需调用 INvDsInferModelConfigComponent 的 API 即可。

接口也充当基类型，注册表和 Composer 等工具可以使用这些基类型来过滤和分组继承自该接口的组件。因此，在上面的示例中，注册表命令 registry comp list -b nvidia::deepstream::INvDsInferModelConfigComponent 可用于查找可以连接到 NvDsInfer 的参数“infer-model-config”的所有组件。Composer 也使用此基类型来提供快速访问上下文菜单，以便在句柄类型参数上创建一个继承自基类型的组件，并将新创建的组件附加到该参数。但是，接口本身是抽象的，不会在 Composer 的组件列表中列出，供用户通过拖放创建实例。

本节的其余部分概述了 DeepStream 扩展提供的接口。这些接口是 NvDsInterfaceExt 扩展的一部分。详细的 API 和参数描述包含在文档《Graph Composer 扩展手册》中。

元素 - INvDsElement

此接口由表示图中 GStreamer 元素的组件使用。元素是基于 GStreamer 的管道的基本构建块。它表示一个处理单元。这些元素可以执行非常具体的任务，例如视频解码或编码，或者它们可以一起执行一组相关任务，例如对象检测 - 预处理、推理和后处理，以获得检测到的对象的边界框坐标。

此接口主要由 NvDsScheduler 组件使用，以管理元素的生命周期并从组件表示的元素构建 GStreamer 管道。它仅应用作基类并从中派生，以创建表示 GStreamer 元素的组件。理想情况下，任何其他组件都不应使用此接口与元素交互。稍后将介绍其他机制。此接口提供以下主要虚拟方法。

gxf_result_t create_element()	具体类型必须使用此方法创建 GStreamer 元素并返回 error/success 状态
gxf_result_t bin_add(GstElement *pipeline)	具体类型必须使用此方法将创建的元素添加到提供的 GStreamer 管道并返回错误/成功状态
GstElement *get_element_ptr()	具体类型必须返回指向 GStreamer 元素的原始指针

大多数实现此接口的组件都是在相应的 GStreamer 元素上创建的瘦包装器。在这种情况下，组件参数和 GStreamer 元素属性之间将存在一对一的映射。存在 NvDsMultiSrcInput 等特殊情况，它们不是单个元素的包装器，而是使用 GStreamer API 将多个元素组合在一起的精细实现。

I/O - INvDsIO/INvDsInput/INvDsOutput

INvDsIO 接口用于表示基于 INvDsElement 的组件的输入/输出。它用于表示 GStreamer Pad，它是 GStreamer 元素的输入/输出端口，元素通过该端口接收/传输数据。方向输入或输出是从组件的角度而不是应用程序的角度来看的。元素从输入接收数据，并在输出上发送数据。输入组件的基类型是 INvDsInput，输出组件的基类型是 INvDsOutput。两者都继承自 INvDsIO。根据 I/O（数据）可用性类型，从 INvDsInput 和 INvDsOutput 派生出多种具体类型，稍后将详细介绍。完整的层次结构如下所示

任何具体的 Pad 类型都可以通过 INvDsIO 接口或 INvDsInput/INvDsOutput 接口或具体的 Pad 类本身进行交互。基于 INvDsElement 的组件具有参数，这些参数的句柄类型是具体的 Pad 类型（取决于方向 - 输入/输出和可用性 - 静态/按需/动态/多路）。在图中，为了使此类组件发送/接收数据，必须将相应类型的 I/O 组件附加到参数。例如，NvDsStreamMux 组件具有“按需”输入和“静态”输出。因此，为了使其接收数据，必须将 NvDsOnRequestInput 组件附加到其 video-in-%u 参数，为了使其发送数据，必须将 NvDsStaticOutput 组件附加到其“video-out”参数。

I/O 由其在元素中的模板名称标识。GStreamer API 可用于使用此模板名称查找有关底层 Pad 详细信息的更多信息。这些接口公开了以下主要虚拟方法

接口	详细信息
void set_template_name(const char *templ)	由基于 INvDsElement 的元素调用，以设置 i/o 的模板名称。
INvDsElement *get_element()	获取 i/o 的基于 INvDsElement 的所有者元素。
const char *get_template_name()	获取 i/o 的模板名称。
GstPadSPtr get_pad(const char *requested_name)	以 shared_ptr 形式获取底层 GstPad 指针。有关每种类型的 I/O 的此 API 的详细行为已在“基本组件”部分的“Pad”子节中记录
const std::vector<GstPadSPtr> get_all_pads()	获取所有底层 GstPad 对象的列表，作为 shared_ptr 的向量。对于多路/按需/动态类型的 I/O，元素可能具有与 I/O 关联的多个底层 Pad。此 API 可用于获取指向所有此类 Pad 的原始指针。

自定义扩展几乎永远不需要从这些接口实现基于 I/O 的组件。所需的所有具体类型都已经作为 NvDsBaseExt 扩展的一部分提供。想要直接与 Pad 交互的自定义组件可以使用此接口中的 API。但是，如果只需要访问正在接收/传输的数据，建议使用基于“Probe”的机制。

连接 - INvDsConnection

INvDsConnection 接口由表示输出组件和输入组件之间链接的组件使用，即两个基于 INvDsElement 的组件之间的链接。具体实现执行连接组件的实际工作。

此接口提供的主要虚拟方法是

方法	详细信息
gxf_result_t connect()	具体实现必须链接源 I/O 和目标 I/O 并返回状态
void disconnect()	具体实现必须取消链接源 I/O 和目标 I/O
bool is_io_compatible(INvDsIO *io, GstPadSPtr gstpad)	检查 I/O 是否与连接另一侧的 I/O 兼容的方法。
void on_pad_added(INvDsIO *io, GstPadSPtr gstpad)	来自动态 I/O 的通知，表明已添加新的底层 GstPad 对象。
void on_pad_removed(INvDsIO *io, GstPadSPtr gstpad)	来自动态 I/O 的通知，表明已删除现有的底层 GstPad 对象。
void on_no_more_pads(INvDsIO *io)	来自动态 I/O 的通知，表明不会再添加新的底层 GstPad 对象。

接口 API 主要由 NvDsScheduler 组件在管道构建期间使用，以链接元素。理想情况下，自定义组件和扩展永远不需要实现基于此接口的组件或使用此接口提供的 API。

上游元素组件的“输出”组件必须附加到基于 INvDsConnection 的组件的“source”参数，下游元素组件的“输入”组件必须附加到“target”参数。

DeepStream 域组件 - INvDsComponent

与图中 DeepStream 组件一起工作的自定义组件应使用 INvDsComponent 接口。此接口的主要功能是它在 Component 接口之上添加了 start() 和 stop() 虚拟方法。

组件通过 start() 方法收到通知，表明图中所有其他组件都已初始化，底层管道已构建并准备好启动。在此方法中，通过组件的句柄调用其他组件的 API 是安全的。这不能保证在 Component 提供的 initialize() 方法中是安全的，因为届时其他组件可能尚未初始化。

stop() 方法在底层管道已停止且组件取消初始化之前调用。

Probe - INvDsProbe

INvDsProbe 接口由表示探针的组件使用。探针用于通过在 INvDsElement 和基于 INvDsElement 的组件的 I/O 组件上添加回调来监视数据流和就地缓冲区修改。

根据使用的标志，对于流经 I/O 的每个缓冲区/查询/事件，都会调用这些回调。基于 INvDsProbe 的组件仅用于安装探针。想要实现这些回调的组件需要实现稍后描述的 INvDsInPlaceDataHandler 接口。

理想情况下，自定义组件和扩展永远不需要实现此接口或使用此接口的 API，NvDsScheduler 需要它来设置探针。

探针回调实现 - INvDsInPlaceDataHandler

想要监视数据流或在组件的特定 I/O 处进行就地数据修改的自定义组件必须从此接口继承。当缓冲区/事件/查询到达 I/O 时，INvDsProbe 基于组件调用此接口的方法。

该接口提供以下虚拟方法。具体实现可以根据需要实现任何方法。

方法	详细信息
bool handle_buffer(GstPad *pad, nvidia::gxf::Entity buffer_data)	向组件发送处理缓冲区数据的通知
bool handle_event(GstPad *pad, GstEvent *event)	向组件发送处理传递的事件的通知
bool handle_query(GstPad *pad, GstQuery *query)	向组件发送处理传递的查询的通知

从这些方法返回 true 会告诉探针组件让它们通过。返回 false 意味着对象应在该点被丢弃。handle_buffer 方法的 buffer_data 参数是一个实体，其中包含以下数据

键	值类型
BUF_DATA_KEY_GST_BUFFER	GstBufferHandle
BUF_DATA_KEY_NVBUFSURFACE	NvBufSurfaceHandle
BUF_DATA_KEY_NVBUFAUDIO	NvBufAudioHandle
BUF_DATA_KEY_GST_VIDEO_BATCH_META	NvDsBatchMetaHandle
BUF_DATA_KEY_GST_AUDIO_BATCH_META	NvDsBatchMetaHandle

值类型在数据组件部分中进行了解释。

根据流经 I/O 的数据类型，并非所有值都可能存在于 buffer_data 实体中。例如，对于处理视频帧的 I/O，buffer_data 可以包含视频的 NvBufSurfaceHandle 和 NvDsBatchMetaHandle，但不包含音频的 NvBufAudioHandle 和 NvDsBatchMetaHandle。

handle_buffer 实现必须先检查值的存在性，然后再直接使用这些值。

基于 INvDsInPlaceDataHandler 的组件必须注册类型为 NvDsProbeConnector 的句柄参数，并在 initialize() 方法中必须调用 NvDsProbeConnector 的 set_handler() 和 set_flags() 方法以接收回调。

有关 GStreamer 查询和事件以及 API 的更多信息，请参阅以下链接

• https://gstreamer.freedesktop.org/documentation/additional/design/query.html

• https://gstreamer.freedesktop.org/documentation/gstreamer/gstquery.html

• https://gstreamer.freedesktop.org/documentation/additional/design/events.html

• https://gstreamer.freedesktop.org/documentation/gstreamer/gstevent.html

Action - INvDsAction

INvDsAction 接口用于表示 GstElement 动作。动作是一个触发器，它向基于 INvDsElement 的组件发出信号，以执行与该触发器相对应的某些动作。

每个支持动作的具体 INvDsElement 基于组件都将具有从 INvDsAction 派生的相应具体类型。此具体类型将公开一种触发动作的方法。

基于 INvDsAction 的组件仅充当辅助组件，用于为触发器提供原型，并将触发动作的组件连接到对触发器做出反应的组件。

触发动作的自定义组件必须单独实现。它必须注册类型为具体 INvDsAction 基于组件的句柄参数。对触发器做出反应的组件也将执行相同的操作。具体的 INvDsAction 基于组件必须附加到其他两个组件的参数。必要时，自定义组件可以通过调用 INvDsAction 基于组件的句柄上的动作触发方法来触发动作，例如 NvDsRecordAction 组件。此动作用于切换相机源的录制开启/关闭录制。因此，此组件具有方法 start_record()、stop_record() 和 take_snapshot()。此动作由 NvDsMultiSrcInputWithRecord 组件支持，因此它具有类型为 NvDsRecordAction 的句柄参数“record-action”。要触发动作，自定义组件必须具有类型为 Handle<NvDsRecordAction> 的参数。组件 NvDsRecordAction 必须添加到图中并附加到 NvDsMultiSrcInputWithRecord 组件和自定义组件的参数。然后，自定义组件可以根据需要调用 start_record()、stop_record() 和 take_snapshot() 方法。

Signal - INvDsSignal

INvDsSignal 接口用于表示 GstElement 信号。信号是来自基于 INvDsElement 的组件的、在某些事件发生时的回调。每个支持信号的具体组件都将具有从 INvDsSignal 派生的相应具体类型。此具体类型将公开回调函数的原型和设置回调函数的方法。

基于 INvDsSignal 的组件仅充当辅助组件，用于为回调提供原型，并将发出信号的组件连接到实现处理信号的回调的组件。

处理信号的自定义组件必须单独实现。它必须注册类型为具体 INvDsSignal 基于组件的句柄参数。它必须实现信号组件公开的 Handler 接口，并在信号组件的句柄上调用 set_handler() 方法。发出信号的组件也将类似地注册类型为具体信号组件的句柄参数。具体的 INvDsSignal 基于组件必须附加到其他两个组件的参数。当基于 INvDsElement 的元素发出相应的信号时，Handler 接口的方法将通过信号组件被调用，例如 NvDsModelUpdateSignal 组件。此信号用于通知动态模型更新的状态。因此，此信号的 Handler 接口具有方法 on_model_updated(int errorCode, char *configFilePath)。此信号由 NvDsInfer 组件发出，因此它具有类型为 NvDsModelUpdateSignal 的句柄参数 model-updated-signal。

要接收信号回调，自定义组件必须实现 NvDsModelUpdateSignal::Handler 接口。它必须注册类型为 Handle<NvDsModelUpdateSignal> 的参数，并在句柄上调用 set_handler()。组件 NvDsModelUpdateSignal 必须添加到图中并附加到 NvDsInfer 和自定义组件的参数。

元素属性控制器 – INvDsPropertyController

INvDsPropertyController 接口由充当基于 INvDsElement 的组件的运行时属性（参数）控制器的组件使用。每个支持运行时属性控制的具体 INvDsElement 基于组件都将具有从 INvDsPropertyController 派生的相应具体类型。此具体类型将公开用于获取/设置元素组件的属性（参数）的方法。将公开每个可以控制的属性的方法。基于 INvDsPropertyController 的组件仅充当辅助组件，用于为 get/set 方法提供原型，并将可以控制属性的组件连接到属性所属的元素组件。

必须单独实现控制属性的自定义组件。它必须注册具体 INvDsPropertyController 基于组件类型的句柄参数。属性所属的组件也将执行相同的操作。具体的 INvDsPropertyController 基于组件必须附加到其他两个组件的参数。在需要时，自定义组件可以调用基于 INvDsAction 的组件（例如 NvDsOSDPropertyController 组件）句柄上的属性的 get/set 方法。此组件可用于获取/设置 NvDsOSD 组件的属性，因此它具有类型为 NvDsOSDPropertyController 的句柄参数 property-controller。

要控制 NvDsOSD 组件的属性，自定义组件必须具有 Handle<NvDsOSDPropertyController> 类型的参数。NvDsOSDPropertyController 组件必须添加到图中，并附加到 NvDsOSD 组件和自定义组件的参数。然后，自定义组件可以调用 NvDsOSDPropertyController 公开的 set/get 方法。

配置 – INvDsConfigComponent 模板和特化

INvDsConfigComponent 接口用作组件的基类，这些组件充当其他组件的配置提供程序（设置集合、关联文件、二进制文件等）。此接口及其派生组件的目标是：

• 简化用例固定的参数组及其值的规范。

• 将所有相关资产（例如，模型文件、自定义实现库）打包在一起

• 消除在部署期间预先知道文件路径的需求，从而避免在 yaml 文件中硬编码这些相关资产文件的路径。由于文件与扩展库一起打包，因此组件可以在内部确定文件的正确绝对路径。

INvDsConfigComponent 接口是一种模板类型。它为任何类型的配置提供了一个标准的虚方法 fill_config(Config *config)，其中 Config 是模板类型。它还提供了一个辅助函数 get_absolute_path(std::string path)，它可以将相对于扩展二进制文件的路径转换为运行时的绝对路径。

想要使用此模板接口读取配置的组件必须声明一个具有受支持配置参数的结构，并通过使用该结构作为模板参数来特化该模板。这些组件必须具有专门化模板的句柄类型的参数。然后可以通过调用句柄的 fill_config() 方法来读取配置。

想要充当配置提供程序的组件必须从专门化的模板继承并实现 fill_config() 方法。配置提供程序组件负责适当地填充配置结构。这些组件可以使用 get_absolute_path() 方法将相对于扩展二进制文件的路径转换为绝对路径。

DeepStream 扩展当前具有以下配置提供程序接口

INvDsInferModelConfigComponent

此接口充当 NvDsInferVideo 和 NvDsInferAudio 组件的配置提供程序。实现此接口的组件必须在 fill_config() 方法中填充配置结构的以下参数。

方法	详细信息
std::string config_file_path	模型 nvinfer 配置文件的绝对路径
std::string model_engine_path	模型预生成的 TensorRT engine 文件的绝对路径（可选）

NvDsInferVideo 和 NvDsInferAudio 组件公开类型为 INvDsInferModelConfigComponent 的句柄参数 infer-model-config，实现此接口的组件可以附加到该参数。

实现此接口的组件是模型配置提供程序。因此，它们将 DeepStreamSDK Gst-nvinfer/ Gst-nvinferaudio 配置文件与模型文件一起打包。Gst-nvinfer 配置文件的规范可以在 https://docs.nvda.net.cn/metropolis/deepstream/dev-guide/text/DS_plugin_gst-nvinfer.html#gst-nvinfer-file-configuration-specifications 中找到。

INvDsVideoTemplatePluginConfigComponent / INvDsAudioTemplatePluginConfigComponent

这些接口分别充当 NvDsVideoTemplate 和 NvDsAudioTemplate 组件的配置提供程序。实现这些接口的组件必须在 fill_config() 方法中填充配置结构的以下参数。

方法	详细信息
std::string customlib_name	音频/视频模板组件应加载的自定义库的绝对路径
std::unordered_map<std::string, std::string> customlib_props	要传递给自定义库的属性的名称-值对。

NvDsVideoTemplate 和 NvDsAudioTemplate 组件分别公开句柄参数 video-template-config 和 audio-template-config，实现 INvDsVideoTemplatePluginConfigComponent 或 INvDsAudioTemplatePluginConfigComponent 接口的组件可以附加到这些参数。实现这些接口的组件将打包必须提供给模板组件的自定义库。NvDsVideoTemplate 和 NvDsAudioTemplate 组件分别是 DeepStreamSDK Gst-nvdsvideotemplate 和 Gst-nvdsaudiotemplate 插件的包装器。有关这些插件的信息，请参阅 https://docs.nvda.net.cn/metropolis/deepstream/dev-guide/text/DS_plugin_gst-nvdsvideotemplate.html 和 https://docs.nvda.net.cn/metropolis/deepstream/dev-guide/text/DS_plugin_gst-nvdsaudiotemplate.html。

数据组件

DeepStream 扩展提供了一些数据组件，这些组件可以作为实体的一部分传递。这消除了拥有固定结构/函数原型来传递数据的需求，从而消除了 API 随着版本更改而中断的问题。实体提供了一种键值机制，用于添加和检索数据组件。键是字符串类型。生成这些实体的组件和使用这些实体的组件都必须知道键与关联值类型之间的映射。使用此类实体的组件还必须通过对实体的 get() 方法的返回值进行布尔检查来检查键值对的存在。本节的其余部分提供了有关 DeepStream 扩展提供的数据组件的详细信息。这些数据组件是 NvDsInterfaceExt 扩展的一部分，并在扩展的 interfaces.hpp 头文件中定义。

GstBufferHandle

包装指向 GstBuffer 的指针，GstBuffer 是 GStreamer 缓冲区的的数据结构 - https://gstreamer.freedesktop.org/documentation/gstreamer/gstbuffer.html 。通常与此数据组件关联的键由 BUF_DATA_KEY_GST_BUFFER 定义。

NvBufSurfaceHandle

包装指向 NvBufSurface 的指针，NvBufSurface 是 DeepStream 批处理视频帧的数据结构 - https://docs.nvda.net.cn/metropolis/deepstream/dev-guide/sdk-api/structNvBufSurface.html 。通常与此数据组件关联的键由 BUF_DATA_KEY_NVBUFSURFACE 定义。

NvBufAudioHandle

包装指向 NvBufAudio 的指针，NvBufAudio 是 DeepStream 批处理音频数据的数据结构 – 链接待定。通常与此数据组件关联的键由 BUF_DATA_KEY_NVBUFAUDIO 定义。

NvDsBatchMetaHandle

包装指向 NvDsBatchMeta 的指针，NvDsBatchMeta 是 DeepStream 与批处理视频帧或批处理音频数据关联的元数据的数据结构 – https://docs.nvda.net.cn/metropolis/deepstream/dev-guide/sdk-api/struct__NvDsBatchMeta.html 。通常与此数据组件关联的键由 BUF_DATA_KEY_VIDEO_BATCH_META 或 BUF_DATA_KEY_AUDIO_BATCH_META 定义，具体取决于 NvDsBatchMeta 结构是否包含视频或音频的信息。

基本组件

本节解释了创建任何类型的基于 DeepStream 的图所需的基本具体组件。所有这些基本组件都是 NvDsBaseExt 扩展的一部分。

I/O

如上一节 INvDsIO 接口中所述，I/O 是基于 INvDsElement 的组件的输入/输出端口。I/O 由一个模板定义，该模板包含：

• 方向（输入或输出）

• 其可用性

• 流经它的数据的格式。

I/O 由模板的名称标识。元素组件将根据其功能和输入/输出要求具有一个或多个 I/O。定义了以下类型的 I/O 可用性以及每种类型 INvDsIO 接口的 GstPadSPtr get_pad(char *requested_name) 方法的行为。

• 静态 – I/O 始终在元素上可用

  • get_pad() 始终返回底层的 GstPad 对象（单个）。requested_name 参数被忽略

• OnRequest – 底层的 I/O 对象必须由应用程序从元素请求

  • 例如，NvDsStreamMux 组件，它聚合来自多个上游组件的帧。必须从中请求用于将数据推送到组件的底层 GstPad 对象，每个上游组件一个。

  • 例如，NvDsTee 组件，它将输入数据广播到多个输出。必须从中请求用于将数据推送到多个下游组件的底层 GstPad 对象，每个下游组件一个。

  • 如果为 get_pad() 提供了非 NULL 的 requested_name，则该方法将尝试使用提供的名称创建底层的 GstPad（如果它尚不存在）并返回它。如果无法创建具有提供的 requested_name 的 pad，则将返回 NULL。如果未提供 requested_name，它将使用从 I/O 模板名称内部生成的名称创建一个底层的 GstPad 并返回它。

• 动态 – 当满足某些条件时，底层 I/O 对象在运行时由元素提供

  • 例如，NvDsSingleSrcInput 组件，它从 FILE 或 RTSP 等输入读取，并且只有在解析文件头/与 RTSP 服务器进行初始通信后才能决定是否可以输出音频或视频或两者都输出。

  • get_pad() 尝试获取具有名称 requested_name 的现有底层 GstPad 对象，如果未找到此类 pad，则返回 NULL。requested_name 是必需的。

• Multi – 为输出来自多个源的数据的组件创建的特殊 I/O 可用性。此可用性将其自身公开为单个 I/O，但在内部将多个输出组合在一起，每个源一个。由于组表示，它使图形和将使用 I/O 的组件独立于源的数量。这使得拥有可变数量的源以及在运行时动态添加/删除源变得容易，而无需对图形进行任何更改。

  • 例如，NvDsMultiSrcInput 组件，它输出来自多个源的数据。

    • get_pad() 尝试获取具有名称 requested_name 的现有底层 GstPad 对象，如果未找到此类 pad，则返回 NULL。requested_name 是必需的。

基于这些概念，提供了以下具体 I/O 类型

• NvDsStaticOutput

• NvDsOnRequestOutput

• NvDsDynamicOutput

• NvDsMultiOutput

• NvDsStaticInput

• NvDsOnRequestInput

元素组件为其支持的每个 I/O 模板公开具体 I/O 类型的句柄参数。对于与 I/O 的任何类型的交互，例如连接两个元素、对流经 I/O 的数据进行就地操作，必须将具体类型的 I/P 组件附加到参数。根据元素组件的功能，组件上将存在各种 I/O 模板以及句柄参数。

连接

连接组件负责连接两个元素。连接两个元素意味着将其中一个元素（称为上游元素）的输出链接到另一个元素（称为下游元素）的输入，这使得数据能够在两个元素之间通过链接的 I/O 流动。提供了两种类型的连接组件

NvDsConnection

此连接组件可用于将任何类型的输出组件链接到任何类型的输入组件，但 NvDsMultiOutput 除外。它提供了两个句柄参数“source”和“target”。要连接，必须将附加到上游元素的输出 I/O 组件附加到 NvDsConnection 组件的“source”参数，并且必须将附加到下游元素的输入 I/O 组件附加到 NvDsConnection 组件的“target”参数。

NvDsMultiSrcConnection

与 NvDsMultiOutput 一样，此连接类型是专门为处理可变数量的源以及在运行时动态添加/删除源的用例而创建的。它只能用于将 NvDsMultiOutput 组件链接到 NvDsOnRequestInput 组件，即链接从多个源输出数据的元素到聚合类型的元素。它有两个参数，“source”用于附加 NvDsMultiOutput 组件，“target”用于附加 NvDsOnRequestInput 组件。

探针

如前所述，探针用于就地操作和监视流经元素组件的 I/O 的数据。提供了两个组件来实现此目的。

NvDsProbe

此组件负责拦截流经 I/O 的数据（缓冲区/事件/查询），并在数据到达 I/O 时调用目标处理程序组件的回调函数。它具有两个句柄类型属性。“io” 用于附加需要探测的 I/O 组件，“probe-handler” 用于附加 NvDsProbeConnector 组件。

NvDsProbeConnector

此组件用于将 NvDsProbe 组件链接到从 INvDsInPlaceDataHandler 派生的目标组件，这使其能够处理来自探针的回调。此组件提供以下公共方法，这些方法在 nvds_probe_connector.hpp 头文件中定义为 NvDsBaseExt 的一部分

方法	详细信息
void set_handler(INvDsInPlaceDataHandler *handler)	设置将处理探针回调的组件。必须由基于 INvDsInPlaceDataHandler 的组件调用。
INvDsInPlaceDataHandler *get_handler()	获取将处理探针回调的组件。
void set_flags(NvDsProbeFlags flags)	设置要接收探针回调的信息类型。必须由基于 INvDsInPlaceDataHandler 的组件调用。
NvDsProbeFlags get_flags()	获取要接收探针回调的信息类型。
void set_io(INvDsIO *io)	设置此组件连接到的 IO。此方法由 NvDsProbe 调用。
INvDsIO *get_io()	获取此组件连接到的 IO。

标志必须是以下各项的按位 OR 组合

方法	详细信息
NvDsProbeFlags::NONE	目标不希望处理任何数据
NvDsProbeFlags::BUFFER	目标组件想要处理缓冲区
NvDsProbeFlags::EVENT	目标组件想要处理事件
NvDsProbeFlags::QUERY	目标组件想要处理查询

目标组件必须注册 NvDsProbeConnector 类型的句柄参数。目标组件在其 initialize() 方法中必须调用 NvDsProbeConnector 的 set_handler() 和 set_flags() 方法以接收回调。

NvDsScheduler

NvDsScheduler 组件负责设置底层管线并管理其状态、连接和调度图中的组件以及管理其生命周期。它还负责设置探针处理程序。

图中必须有一个 NvDsScheduler。如果图中没有 NvDsScheduler，则基于 DeepStream 的组件永远不会被调度。此外，图中必须只有一个 NvDsScheduler。如果将多个 NvDsScheduler 添加到图中，则只会实际执行一个，其他组件将变得冗余并被跳过。