Functions and Restrictions
Function Description
Table 1 describes the functions of media data processing V1 (Digital Vision Pre-Processing, DVPP).
|
Function |
Function |
|---|---|
|
Vision Preprocessing Core (VPC) |
Supports image cropping, resizing, and format conversion. For details, see Restrictions. |
|
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 VDEC Functions and Restrictions. |
|
Video Encoder (VENC) |
Encodes videos. For details, see VENC Functions and Restrictions. |
|
PNG Decoder (PNGD) |
Decodes PNG images. For details, see PNGD Functions and Restrictions. |
Functions supported by each product model
Table 2 describes the functions of media data processing V1 supported by each product model.
- √: supported.
- x: not supported
|
Model |
VPC |
JPEGD |
JPEGE |
PNGD |
VDEC |
VENC |
|---|---|---|---|---|---|---|
|
|
√ |
√ |
√ |
√ |
√ |
☓ |
|
|
√ |
√ |
√ |
√ |
√ |
√ |
|
|
√ |
√ |
√ |
√ |
√ |
√ |
|
|
√ |
√ |
√ |
√ |
√ |
☓ |
|
|
√ |
√ |
√ |
√ |
√ |
☓ |
|
Atlas 350 Accelerator Card |
☓ |
☓ |
☓ |
☓ |
☓ |
☓ |
Restrictions
When using the APIs described in this chapter, pay attention to the following points:
- About asynchronous APIs
For the asynchronous APIs described in this section, successful API calling only indicates that the task is successfully delivered, not the task execution. For asynchronous APIs that depend on each other, you are advised to specify the same stream in multiple asynchronous APIs to ensure that tasks can be executed in sequence. This is because tasks in the same stream are executed in the API call sequence. After the asynchronous API is called, resources cannot be released immediately. You need to call the synchronous waiting API (for example, aclrtSynchronizeStream) to ensure that the resources can be released only after the task on the device is complete. To ensure performance, you are advised to call aclrtSynchronizeStream once after multiple asynchronous API tasks are delivered to a stream.
- About memory allocation and deallocation:
- Before implementing the VPC, JPEGD, and JPEGE functions for media data processing, if you need to allocate memory on the device to store the input or output data, call the acldvppMalloc API to allocate memory and call the acldvppFree API to free the memory. If multiple functions are used in cascade and the same memory segment needs to be reused, allocate the maximum allowed 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 overcommitment and reduce memory copy.
- However, the address space accessed by media data processing is limited. To ensure that the memory is sufficient during media data processing, you are advised to call other memory allocation APIs (such as the aclrtMalloc API) for other functions (such as model loading) except media data processing.
- About channel requirements
Before implementing the media data processing function, you must call the corresponding API to create a channel. For details about the API for creating a channel, see Channel creation and destruction. Channel creation and destruction involve resource allocation and release. Repeated channel creation and destruction 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.
The maximum number of channels for each media data processing function is as follows: