General Description
API Differences Between Versions
- In this document, the media data processing APIs in the V1 and V2 versions have the same functions. Both of them are used to implement functions such as image cropping, image resizing, and format conversion. However, these two sets of APIs must not be mixed together.
- V2 APIs are recommended, which guarantee continuous evolution of API functions and services in later versions.
- V1 APIs are retained for backward compatibility considerations, but will be deprecated in later versions.
Function Usage
Table 1 describes the functions of media data processing V1 (Digital Vision Pre-Processing, DVPP).
Function |
Description |
|---|---|
Vision Preprocessing Core (VPC) |
Processes images, including cropping, resizing, and format conversion. For details, see Function Usage. |
JPEG Decoder (JPEGD) |
Decodes .jpg, .jpeg, .JPG, and .JPEG images into YUV images. For details, see Functions and Restrictions. |
JPEG Encoder (JPEGE) |
Encodes YUV images into .jpg images. For details, see Functions and Restrictions. |
Video Decoder (VDEC) |
Decodes videos. For details, see Functions and Restrictions. |
Video Encoder (VENC) |
Encodes videos. For details, see Functions and Restrictions. |
PNG Decoder (PNGD) |
Decodes PNG images. For details, see Functions and Restrictions. |
Function Support
Table 2 describes the functions of media data processing V1 supported by products.
- √: Supported
- x: Not supported
Product |
VPC |
JPEGD |
JPEGE |
PNGD |
VDEC |
VENC |
|---|---|---|---|---|---|---|
√ |
√ |
√ |
√ |
√ |
√ |
|
√ |
√ |
√ |
√ |
√ |
x |
|
√ |
√ |
√ |
√ |
√ |
x |
|
√ |
√ |
√ |
√ |
√ |
√ |
|
√ |
√ |
√ |
√ |
√ |
x |
Restrictions
When using the APIs described in this chapter, pay attention to the following points:
-
For the asynchronous APIs described in this chapter, a successful API call only indicates the success of the task delivery, regardless of the execution result. For dependent APIs, you are advised to specify the same stream for multiple APIs to ensure tasks execution sequence, because tasks in the same stream are executed in accordance with the API call sequence.
When asynchronous APIs are called to decode, crop, and resize images, if tasks depend on each other, call acl.rt.synchronize_stream to ensure that tasks in the stream are executed in sequence.
To ensure the performance, it is recommended that acl.rt.synchronize_stream be called once after multiple asynchronous media data processing tasks are delivered to a stream.
After an asynchronous API is called, resources cannot be destroyed immediately. You need to call a synchronization API (for example, acl.rt.synchronize_stream) to confirm that the requested tasks of the device have been completed.
About memory allocation and deallocation
- If device memory is needed to store the input or output data before implementing the VPC, JPEGD, and JPEGE functions for media data processing, call acl.media.dvpp_malloc to allocate memory and acl.media.dvpp_free to free up memory.
- The memory allocated in 1 can be used for media data processing and other tasks. For example, the output of media data processing can be used as the input of model inference to implement memory reuse and reduce memory copy.
- Because the address space accessed by media data processing is limited, you are advised to call acl.rt.malloc, acl.rt.malloc_host, or acl.rt.malloc_cached described in section "Memory Management" to allocate memory for other functions (for example, model loading) to ensure sufficient memory during media data processing.
- About channel requirements
Before implementing each function of media data processing, you must call APIs to create corresponding channels. For details, see Channel Creation and Destruction. Channel creation and destruction involve resource allocation and release. Repeated channel creation and destruction, however, affect service performance. Therefore, you are advised to manage channels based on your actual scenario. For example, to process VPC images continuously, create VPC channels, wait until all VPC functions are called, and then destroy the VPC channels.
Too many channels would affect the CPU usage and memory usage of the device. For details about the number of channels, see the performance specifications in the corresponding function sections.
On the
Atlas inference products , the number of channels for each function is limited. VPC supports a maximum of 256 channels. JPEGD and VDEC share a maximum of 256 channels. JPEGE and VENC share a maximum of 256 channels. PNGD supports a maximum number of 128 channels. For details about the APIs for channel creation, see Channel Creation and Destruction.On the
Atlas A2 training products /Atlas A2 inference products , the number of channels for each function is limited. VPC supports a maximum of 256 channels. JPEGD supports a maximum of 256 channels. VDEC supports a maximum of 128 channels. JPEGE supports a maximum of 256 channels. PNGD supports a maximum of 128 channels. For details about the APIs for channel creation, see Channel Creation and Destruction.On the
Atlas 200I/500 A2 inference products , the number of channels for each function is limited. VPC supports a maximum of 128 channels. JPEGD supports a maximum of 128 channels. VDEC supports a maximum of 128 channels. JPEGE supports a maximum of 128 channels. VENC supports a maximum of 128 channels. PNGD supports a maximum of 128 channels. For details about the APIs for channel creation, see Channel Creation and Destruction.
For Ascend virtual instances on the
- Total number of VPC channels = (Number of allocated VPC hardware units/Total number of VPC hardware units) x 256
- Total number of VDEC and JPEGD channels = (Total number of allocated VDEC and JPEGD hardware units/Total number of VDEC and JPEGD hardware units) x 256
- Total number of VENC channels and JPEGE channels = (Total number of allocated VENC and JPEGE hardware units/Total number of VENC and JPEGE hardware units) x 256
- Total number of PNGD channels = Allocation specification x 128
For the PNGD function, the restrictions on the number of channels are different based on the following Ascend virtual instance templates:
- When the vir04_4c_dvpp template is used, the total number of channels is fixed at 128.
- When the vir04_3c_ndvpp template is used, the DVPP function is not used. Therefore, the total number of channels is 0.
For Ascend virtual instances on the
- A maximum of 256 VPC channels are supported.
- Total number of VDEC channels = (Number of allocated VDEC hardware units/Number of VDEC hardware units) x 32. If the total number of channels is not an integer, round down the value. The number of JPEGD channels is not affected by the computing power. However, the maximum number of JPEGD+VDEC channels is 256.
- A maximum of 256 JPEGE channels are supported.
- Total number of PNGD channels = Allocation specification x 128For the PNGD function, the restrictions on the number of channels are different based on the following Ascend virtual instance templates:
- When the vir12_3c_32g_m, vir10_3c_16g_m or vir10_3c_32g_m profile is used, the total number of channels is fixed to 128.
- When the vir12_3c_32g_nm, vir10_3c_16g_nm or vir10_3c_32g_nm template is used, the DVPP function is not used. Therefore, the total number of channels is 0.
For Ascend virtual instances on the
- A maximum of 128 VPC channels are supported.
- Total number of VDEC channels = (Number of allocated VDEC hardware units/Number of VDEC hardware units) x 128. If the total number of channels is not an integer, round down the value. The number of JPEGD channels is not affected by the computing power. However, the maximum number of JPEGD+VDEC channels is 128.
- Total number of VENC channels = (Number of allocated VENC hardware units/Number of VENC hardware units) x 128. If the total number of channels is not an integer, round down the value. The number of JPEGE channels is not affected by the computing power. However, the maximum number of JPEGE+VENC channels is 128.
You can run the npu-smi info -t template-info command on the server where Ascend AI Processor is installed to view the computing power specifications of the Ascend virtual instance in each scenario.