3.2. Design Overview¶
3.2.1. Video Memory Block Pool¶
The video memory buffer pool mainly provides large physical memory management function for each module (VI/VPSS/VO/VDEC/VENC/GDC…), and is responsible for the acquisition, allocation and recovery of memory, so that the physical memory resources can be shared in each media processing module, and unnecessary copying action can be avoided.
Multiple groups of blocks with the same size and continuous physical address form a video buffer pool. The common video chunk pool must be configured before system initialization. Depending on the required functions, the number of public block pools, the size and number of blocks should increase or decrease accordingly.
The number of video buffer pools should be considered as follows:
For each additional channel, you need to add two (ping-pong buffer).
VO, determined by DisplayBufLen, is an exception to condition 1. The minimum number is 3.
If the u32Depth of channel is not 0, the number of u32Depth needs to be increased.
Each time an LDC function (lens distortion, rotation, etc.) is added, a memory block pool needs to be added.
In the case of enough memory space, you can take the maximum space to establish a public video buffer pool; To reduce the memory usage, it is recommended to use multiple public video buffer pools of different sizes.
All video processing channels can obtain video blocks from the common video block pool to save the captured images, as shown in Figure 2-1
VI first obtains the video buffer Ai from the public video buffer pool A to store the video data received from the sensor.
When VI finishes capturing, the buffer Ai will be sent to the VPSS through the VI, and the VPSS channels 0 and 1 also obtain the video blocks Aj and Ak from the public video block pool A.
When VPSS finishes its work, the input buffer Ai will be released back to the public video buffer pool, and Aj will be sent to VENC as the output image buffer, and Ak will be sent to VO as the output image buffer.
Aj is released to the public video buffer pool after encoded by VENC, and Ak is released to the public video buffer pool after displayed by VO.
Table 3- 1 Introduction of video buffer pool size calculation interface in cvi_buffer.h
Video block pool sizecalculation interface |
Interface introduction |
|---|---|
COMMON_GetPicBufferConfig |
Data size of each component in the general linear format |
COMMON_GetPicBufferSize |
The block pool in a general linear format |
3.2.2. System Binding¶
SDK provides system binding interface (CVI_SYS_Bind), that is to establish the relationship between data sources and data receivers by binding them.
After binding, the data generated by the data source will be automatically sent to the receiver.
A data source can be bound to multiple data receivers.
If the data source is not bound, it will eventually automatically return to the video memory buffer pool.
The currently supported binding relationships are shown in table 3-2.
Table 3- 2 Supported binding relationships
Data Source |
Data Receiver |
|---|---|
VI |
VPSS |
VENC |
|
VO |
|
VPSS |
VO |
VENC |
|
VPSS |
|
VDEC |
VPSS |
VENC |
|
VO |
|
Audio Input |
AENC |
Audio Output |
|
ADEC |
Audio Output |
3.2.3. The Working Mode of VI and VPSS¶
The working modes of VI and VPSS are divided into online and offline modes. The description of working modes is shown in table 3-3.
Table 3- 3 Description of the working mode of VI and VPSS
Mode |
VI_CAP and VI_PROC |
VI_PROC and VPSS |
|---|---|---|
Online mode |
VI_CAP and VI_PROC transmit data stream online. In this mode, VI_CAP sends data stream to VI_PROC directly, but does not write RAW data to memory. |
VI_PROC and VPSS transmit data stream online. In this mode, VI_PROC directly sends the data stream to VPSS instead of writing YUV data to memory. |
Offline mode |
VI_CAP writes raw data to memory, then VI_PROC reads raw data from memory for post-processing. |
VI_PROC writes YUV data to memory, then VPSS reads YUV data from memory for post-processing. |
The VI PIPE can be configured to operate in multiple modes, which are described as follows:
The 0 (long exposure) pipe can have 4 modes
VI online VPSS offline
VI online VPSS online
VI offline VPSS offline
VI offline VPSS online
Other PIPE, if marked as “-” in the following table of working modes, it means that YUV cannot be operated independently, only the previous PIPE can operate in HDR.
Table 3- 4 VI PIPE working modes
PIPE ID |
0 (long exporsure) |
1 (short exposure) |
2 (long exporsure) |
3 (short exposure) |
|---|---|---|---|---|
Patterndistribution1 |
Offline |
Offline |
Offline |
Offline |
Patterndistribution2 |
Online |
Online |
3.2.4. The Working Mode of VPSS¶
The VPSS can operate in two modes, namely SINGLE mode and DUAL mode.
Processor |
Mode |
Device |
Number of channels |
|---|---|---|---|
CV181x |
SINGLE |
0 |
4 |
DUAL |
0 |
1 |
|
1 |
3 |
||
CV180x |
SINGLE |
0 |
3 |
DUAL |
0 |
1 |
|
1 |
2 |
The default setting is SINGLE.
If it is not SINGLE, it is necessary to specify the operating VPSS device when the VPSS group is created.
3.2.5. Alignment Requirements For The Video Pipeline¶
When processing data from MEMORY, the modules of each processor have different requirements. Alignment is the reading and writing amount of each line in image processing, which needs to be a multiple of the lines.
For example: YUV420 PLANAR format is 720x480.
Therefore, Y is the data amount of ALIGN(720, 32) x 480 = 736 x 480, and U/V is ALIGN(360, 32) x 240 = 384 x 240.
It can be modified through APIs such as CVI_VPSS_SetChnAlign, but cannot be less than the hardware limit.
Processor |
Module |
Alignment |
|---|---|---|
CV181x/CV180x |
VI |
64 |
VPSS |
64 |
|
VO |
64 |
3.2.6. Dual OS Communication¶
If it is a dual OS SDK, it is necessary to initialize the dual-core communication message at the beginning, and the subsequent API can only be called after the communication with the small core is established.
Dual-core communication message initialization API: CVI_MSG_Init