Overview

API Differences Between Versions

• In this document, the media data processing APIs in the V1 and V2 versions have the same functions such as video encoding and decoding, image encoding and decoding, and image processing. Nevertheless, these two sets of APIs must not be mixed together.
  • V2 has more functions than V1. For example:
    • JPEGE: The APIs in the V2 version support advanced parameter configuration, such as Huffman table configuration.
    • VENC: The APIs in the V2 version support more refined configuration of bit rate control parameters and effect tuning, such as the QP of I-/P-frames and macroblock bit rate control.
    • VDEC: The APIs in the V2 version support more refined memory control, such as the setting of the input stream buffer.
  • 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 Description

Table 1 describes the functions of media data processing V1 (Digital Vision Pre-Processing, DVPP).

Function Support

Table 2 describes the functions of media data processing V1 supported by each product model.

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, 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 aclrtSynchronizeStream to ensure that tasks in the stream are executed in order.

  To ensure the performance, it is recommended that aclrtSynchronizeStream be called once after multiple asynchronous media data processing tasks are delivered to a stream.

  After an asynchronous API is called, do not destroy the allocations immediately. Call the synchronization API (for example, aclrtSynchronizeStream) to confirm that the requested tasks of the device have been completed.

• About memory allocation and deallocation
  1. 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 acldvppMalloc to allocate memory and acldvppFree to free up memory. If multiple functions are used in cascade and the same memory segment needs to be reused, allocate the maximum allowed memory.
  2. 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.
  3. Because the address space accessed by media data processing is limited, you are advised to call the APIs under Memory Management (such as aclrtMalloc and aclrtMallocHost) to allocate memory for other functions (such as 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.

  A too large number of 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.