Process Orchestration
Service Process
By using the pipeline configuration file, the stream manager can identify the elements to be constructed and the connection between the elements, and start the service process. The stream manager provides APIs for external systems to send data to and obtain results from the stream, helping implement service interconnection.
A plugin is the basic module in the service process. A stream is constructed by concatenating elements. The buffer is used to mount the video and image data before and after decoding, which is the data structure transferred between elements. In addition, the buffer allows users to mount metadata to store structured data (such as the object detection result) or process data (such as the resized image).
|
Name |
Class Name |
Description |
Remarks |
|---|---|---|---|
|
Stream |
MxStream |
Service stream |
A complete inference service stream, which is concatenated by plugins. |
|
Stream manager |
MxStreamManager |
Service stream management module |
Builds and destroys streams, and provides APIs for sending data and obtaining results. |
|
Plugin |
MxPlugin |
Function plugin |
A functional module in a service stream, which is the basic unit of the service stream. |
|
Element |
None |
Function element |
Object generated after the .so plugin is instantiated. The same .so plugin can instantiate multiple objects, as shown in the two image resizing elements in Figure 1. |
|
Plugin Buffer |
MxpiBuffer |
Plugin buffer |
Unstructured data transmitted between plugins, such as video and image data before and after decoding. |
|
Plugin Metadata |
MxpiMetadata |
Plugin metadata |
Structured data generated by the plugin, such as classification information and target information. It is attached to the plugin buffer for transmission. |
Data Flow
To help you understand the data structure transfer process between plugins, the following procedure uses an image as the input and describes the data transfer process in detail based on the code.
- Create a variable MxstDataInput for storing the input image and use the ReadFile function to read the image data to the variable dataBuffer.
1 2
MxStream::MxstDataInput dataBuffer; APP_ERROR ret = ReadFile("./test.jpg", dataBuffer);
- Create a stream management object MxStreamManager, initialize the object, and load the pipeline file.
1 2 3 4
MxStreamManager *mxStreamManager = new MxStream::MxStreamManager(); ret = mxStreamManager->InitManager(); string streamsConfig = "detection.pipeline"; // The detection.pipeline file can contain one or more service streams. APP_ERROR ret = mxStreamManager->CreateMultipleStreams(streamsConfig); // The method for processing multiple service streams is used.
- Use the SendData function to pass the input data to the image obtaining module.
1ret = mxStreamManager->SendData(streamName, inPluginId, dataBuffer); // streamName is the name of the service stream in the pipeline file. inPluginId indicates the input port number, corresponding to the input element number.
- Process data in the Process function of each plugin.
- Receive the buffer data of the previous plugin and the metadata mounted to the buffer.
1 2 3
MxpiFrame inputMxpiFrame = GetHostDataInfo(*mxpiBuffer); // If the data is on the device, call the GetDeviceDataInfo function. MxpiMetadataManager mxpiMetadataManager(*mxpiBuffer); // Create a metadata manager object. shared_ptr<void> metadata = mxpiMetadataManager.GetMetadata("keyName"); // Obtain the metadata mounted to the buffer based on the key name. keyName is the name of the previous plugin.
- Process the service logic.
1 2
DataProcess(inputMxpiFrame, metadata, outputMetadata); // Data processing functions implemented in the plugin, such as decoding, resizing, and inference. mxpiMetadataManager.AddMetadata("keyName", outputMetadata); // Mount outputMetadata to the buffer. keyName is usually the name of the current plugin.
- Send buffer data to the next plugin.
1SendData(inPlugin, *mxpiBuffer); // Call the SendData method of MxPluginBase to send data to the next plugin.
- Receive the buffer data of the previous plugin and the metadata mounted to the buffer.
- Use the GetResult function to obtain the output result of the last plugin.
1MxStream::MxstDataOutput* output = mxStreamManager->GetResult(streamName, outPluginId); // outPluginId indicates the output port number, corresponding to the output element number.
Introduction to the Pipeline Configuration File
Figure 3 and Figure 4 are pipeline configuration file samples for an inference service stream, including a service stream name, stream configuration, an element name, a plugin name, element properties, and a downstream element name.
The configuration file is in JSON format. You must specify the service stream name, element name, and plugin name, and add element properties and the downstream element name as required. Otherwise, the stream will fail to be created and errors will occur. For details, see Table 2.
|
Name |
Mandatory/Optional |
Description |
|---|---|---|
|
Service stream name (stream) |
Mandatory |
Specifies the stream entity to be operated. For example, when the stream manager sends data, the stream name needs to be specified. |
|
Stream configuration (stream_config) |
Mandatory |
Sets the configuration parameters of the stream. For example, Device ID specifies the device on which the stream runs. |
|
Element name (element) |
Mandatory |
Constructs a plugin entity in the stream, that is, a plugin object. This item is used together with the downstream element name to define the connection between elements. You are advised to name the item in the format of plugin base class name + serial number and ensure that the name is unique in the stream. ReserveMetadataGraph and ReservedVisionList are reserved fields and cannot be set. |
|
Plugin name (factory) |
Mandatory |
Used to build elements. You can obtain the value by referring to Plugins. |
|
Element properties (props) |
Optional |
Used to modify configuration parameters based on service features. For example, in the image resizing plugin, the properties specify the width and height of the output image. Each property has a default value. For details, see Plugins. |
|
Downstream element name (next) |
Mandatory (except the last element in the stream) |
Used to determine the functions of the downstream element based on specific services. The data generated by this plugin will be transmitted to the downstream element. If there are multiple downstream plugins, separate them with commas (,). The port number is after the colon (:), and is enclosed in square brackets ([]). ReserveMetadataGraph and ReservedVisionList are reserved fields and cannot be set. |
|
Name of the downstream metadata receiving element (nextMeta) |
Optional |
Used to set the plugin with multiple input ports to determine functions of the downstream metadata receiving element. The metadata generated by the plugin is transferred to the downstream element. If there are multiple downstream plugins, separate them with commas (,) and enclose them in square brackets. You can add a port number after the colon (:) to specify the input sequence of the same downstream element. If no port number is added, the default input sequence is used. |
Common attributes can be directly configured under props. For details, see Table 3.
|
Name |
Mandatory/Optional |
Description |
|---|---|---|
|
dataSource |
Optional (You are advised to use the upstream nextMeta property.) |
Indicates the data processed by the process function of the plugin. It is an upstream Vision SDK plugin, and the native GStreamer plugin is not supported. The value is of the string type, and defaults to auto. This value is specified by nextMeta of one or more upstream plugins. If an upstream plugin does not add nextMeta to the plugin, the plugin uses dataSource. Otherwise, the plugin uses nextMeta. |
|
status |
Optional |
Specifies whether the plugin is executed synchronously or asynchronously. The value is of the int type and can be 0 or 1. The value 0 (default) indicates asynchronous execution, and the value 1 indicates synchronous execution. Exercise caution when setting this parameter. |
|
deviceId |
Optional |
Specifies the ID of the device on which the plugin runs. The value is of the int type. The default value is 0. Currently, a single stream can run on only one device. You can specify deviceId in Stream_config. |
The property value is a string regardless of whether the data type of the property is string. For example, "resizeWidth": "2048" is used instead of "resizeWidth": 2048.
Process Orchestration for Multi-input/output Plugins

If an element contains multiple output ports, use square brackets ([]) to enclose multiple elements specified by next and commas (,) to separate the elements, as shown in Figure 5.
The element serial number specified in [] corresponds to the output port of the current element. That is, the first element in [] is associated with port 0 of the current element, the second element is associated with port 1, and so on.
Setting deviceId in Batches
Add deviceId (default value: 0) corresponding to the stream_config field to the pipeline configuration file. In this way, you can set device IDs in batches, as shown in Figure 6.
You need to configure stream_config for each stream.
Code Process Orchestration
Code process orchestration refers to creating streams by using a composition method similar to a deep learning framework to avoid writing complex pipeline files. In this way, the process orchestration can be quickly and efficiently implemented. Table 4 lists the key functions. For details about the compilation example, see Figure 7.
|
Name |
Class Name |
Description |
Description |
|---|---|---|---|
|
PluginNode |
PluginNode |
Plugin node |
Defines a plugin, including its name, type, and properties. |
|
Stream |
Stream |
Service stream |
A complete inference service stream, which is concatenated by plugins. |
|
Sequential Stream |
SequentialStream |
Sequential service stream |
Processes sequential services, that is, the plugins are in a sequential relationship. |
|
Functional Stream |
FunctionalStream |
Functional service stream |
Processes complex relationships such as multi-input multi-out (MIMO) process. |
The code orchestration process is divided into four steps.
- (Optional) Configure properties based on the plugin requirements.
- Create service streams and configure the processor. Service streams are used for subsequent plugin combination and data processing.
- Create plugin nodes and construct inference process.
- Process data. After an input object is created, SendData and GetResult of the stream are used to transfer data and obtain results.





