Functions and Restrictions

Typical Functions of Image/Video/Audio Data Processing

Figure 1 Image/Video data processing

The following table describes the functions. For details about the media data processing functions supported by each product model, see Functions supported by each product model. The current AIPP versions support all the functions.

Description	Sub-Function Module	Description
Obtain video data.	Image signal processing (ISP) system control	The system control function is used to register the 3A algorithm, register the sensor driver, initialize the ISP firmware, run the ISP firmware, exit the ISP firmware, and configure the ISP attributes.
Obtain video data.	MIPI Rx ioctl command	MIPI RX is a collection unit that supports multiple differential video input interfaces. It receives data from the MIPI, LVDS, sub-LVDS, and HiSPI interfaces through the combo PHY. MIPI RX supports data transmission at multiple speeds and resolutions by configuring different function modes and supports multiple external input devices.
Obtain video data.	Video Input (VI)	The VI module captures video images, performs operations such as cropping, color optimization, brightness optimization, and noise removal on the images, and outputs YUV or RAW images.
Display video data.	VO (Video Output)	The VO module receives the images that have been processed by VPSS, controls the playing of the images, and outputs the images to peripheral video devices based on the configured output protocols (only HDMI is supported now). The VO module can work with the two-dimensional engine (TDE) module and HiSilicon Framebuffer (HiFB) module to draw graphics and manage graphics layers by leveraging hardware.
Display video data.	High Definition Multimedia Interface (HDMI)	HDMI is an all-digital image and audio sending interface that can send uncompressed audio and video signals.
Display video data.	Two-Dimensional Engine (TDE)	The TDE is a two-dimensional graphics acceleration engine. It uses hardware to provide fast graphics drawing functions for the On Screen Display (OSD) and Graphics User Interface (GUI). The functions include quick copy, quick color filling, and pattern filling. (Currently, only alpha blending is supported.)
Display video data.	HiSilicon Framebuffer (HiFB)	The HiFB is used to manage overlaid graphics layers. It not only provides the basic functions of Linux framebuffer, but also provides extended functions such as modifying the display start position of a graphics layer and inter-layer alpha.
Region Management	Region	The overlaid on screen displays (OSDs) and color blocks in a video are called regions. The REGION module is used to manage the region resources in a unified manner. It is used to display specific information (such as the channel ID and PTS) on the video or fill color blocks in the video for covering. Currently, this function must be used together with VPSS.
Image/Video Data Processing	Video Process Sub-System (VPSS)	The VPSS module preprocesses input images in a unified manner, such as denoising, deinterlacing, and cropping, and then processes each channel separately, such as scaling and bordering.
Image data processing	Artificial Intelligence Pre-Processing (AIPP)	AIPP implements functions on the AI Core, including image resizing (such as cropping and padding), CSC, mean subtraction, and factor multiplication (for pixel changing). AIPP supports static and dynamic modes. However, the two modes are mutually exclusive. Static AIPP: If you use this mode and specify the AIPP parameters when converting a model, the AIPP attribute values are saved in the offline model (.om file) after the model is generated. Fixed AIPP configurations are used in each model inference. In static AIPP mode, batches share the same set of AIPP parameters. The AIPP parameters are set when the ATC tool is used for model conversion. For details about the ATC tool, see ATC. Dynamic AIPP: When converting a model, set the AIPP mode to dynamic. Whenever you need to run the model for inference, first set the AIPP configurations to implement application-specific AIPP preprocessing.
Image/Video Data Processing	Digital Vision Pre-Processing (DVPP)	DVPP is an embedded image processing unit of the AI processor. It provides powerful hardware acceleration capabilities for media processing through media data processing APIs. It provides the following functions: Vision Preprocessing Core (VPC): Processes YUV and RGB images, including resizing, cropping, pyramid, and CSC. JPEG Decoder (JPEGD): decodes images from JPEG to YUV. JPEG Encoder (JPEGE): Encodes images from YUV to JPEG. Video Decoder (VDEC): Decodes video streams from H.264/H.265 to YUV/RGB. Video Encoder (VENC): Encodes video streams from YUV420SP to H.264/H.265. PNG Decoder (PNGD): Decodes images from PNG to RGB. AIPP and DVPP can be used separately or together. In combined applications, DVPP is used first to decode, crop, and resize images or videos. However, due to DVPP hardware restrictions, the image format and resolution after DVPP may not meet the model requirements. Therefore, AIPP is required to further perform CSC, image cropping, and border making. For example, for Atlas 200/300/500 inference product and Atlas training product, because DVPP video decoding supports only YUV images, if the model requires RGB images, AIPP color space conversion is required.
Obtain and output audio data.	Audio Input (AI)	The AI module captures audio data.
Obtain and output audio data.	Audio Output (AO)	The AO module can play the audio data decoded by the ADEC module.
Encode and decode audio data.	Audio Encoder (AENC)	The AENC module encodes the audio data obtained by using the AI module and outputs audio streams.
Encode and decode audio data.	Audio Decoder (ADEC)	The ADEC module decodes G.711a, G.711u, and other audio streams and plays audios through the AO module.

Functions supported by each product model

The following table describes the functions of media data processing V2 supported by each product model.

The meanings of the identifiers are as follows:

√: Yes

x: Not supported

Model	VPC	JPEGD	JPEGE	PNGD	VDEC	VENC	Video Data Obtaining	VPSS Video Processing	Audio Functions (Recording/Playing/Volume Adjustment)	Video Data Display	Region Management
Atlas training product	☓	☓	☓	☓	☓	☓	☓	☓	☓	☓	☓
Atlas inference product	√	√	√	√	√	√	☓	☓	☓	☓	☓
Atlas 200I/500 A2 inference product	√	√	√	√	√	√	√	√	√	√	√
Atlas A2 training product/Atlas A2 inference product	√	√	√	√	√	☓	☓	☓	☓	☓	☓
Atlas A3 training product/Atlas A3 inference product	√	√	√	√	√	☓	☓	☓	☓	☓	☓
Atlas 350 Accelerator Card	√	√	√	√	☓	☓	☓	☓	☓	☓	☓

Restrictions

When using the APIs described in this chapter, pay attention to the following points:

About memory allocation and deallocation:
1. Before implementing some media data processing functions such as VPC, JPEGD, and JPEGE, you need to allocate memory to store the input or output data. The media data processing functions have higher requirements on the memory for storing the input and output data. Therefore, you need to call dedicated memory allocation APIs. For details, see the restrictions in sections that describe the functions. 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. However, the address space accessed by media data processing is limited. To ensure sufficient memory during media data processing, you are advised to call other memory allocation APIs (such as aclrtMalloc) 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, see the channel creation and destruction APIs in the VPC, VDEC/JPEGD, Video Encoding (VENC) and JPEG Encoder (JPEGE), and PNG Decoder (PNGD) sections.

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.
This section describes the structs and enumerations. The reserved fields must be manually set to 0 to avoid incompatibility with future versions.
The reserved fields in the structs and enumerations contain a _BUTT suffix, for example, HI_COMPRESS_MODE_BUTT.

Parent topic: Media Data Processing V2 APIs