|
How
video acquisition internally work ?
The VIN Module captures video into frames. Frames
are alllocated contiguously in a circular buffer
provided by user before openning the module. This buffer
must be large enough to allow at least 3 frames to be
stored. Using a 3 frames buffer is the best way to
insure that you won't have any overlapping between the
background capture and the processing.
If your process need to work on more than 1 frame (for
example when working on motion estimation), you don't
need to copy frames to another buffer, you just have to
create a buffer large enough and tell the VIN module to
always leave the last N frames untouched.
The video input module use the EDMA channel for external
event interrupt 4.
In CIF or QCIF resolution, we also use the first reload
table available. When we want to update the address for
next frame transfert, we update the destination address
in a reload table.
In FULL resolution mode, as we have frames I and P, we
need to use 4 reload tables. These tables are dynamicly
allocated by CSL. The first two reload tables are used
for a complete picture (I+P). When we want to update a
picture, we first update the destination address in the
2 remaining reload tables and then we link the first P
reload table on the I remaing reload table. And so on.
For each end of EDMA transfer, the Transfer Complete
Code (TCC) used is EDMA_CHA_GPINT1.
The EDMA channel used is the channel 4 (which correspond
to external interrupt 4)
How
video restitution internally work ?
The VOUT Module generates video from frames provided
by the user. Frames are allocated by the user.
Their memory location is non important, as far as each
frame start is aligned on a 32 bit word boudary.
Frames for video generation don't need to be
contiguously allocated in the same buffer like the ones
used for video capture. They even doesn't need to be
allocated before openning the module.
The video output module use the EDMA channel for
external event interrupt 5 (COMPOSITE output) or
external event interrupt 6 (VGA output)
In CIF resolution, we also use the first reload table
available available. When we want to update the address
for next frame transfert, we update the source address
in reload table and in the current EDMA transfert In
FULL resolution mode, as we have frames I and P, we need
to use 4 reload tables. These tables are dynamicly
allocated by CSL. The first two reload tables are used
for a complete picture (I+P).
When we want to update a
picture, we first update the source address in the 2
remaining reload tables and then we link the first P
reload table on the I remaing reload table. And so on.
For each end of EDMA transfer, the Transfer Complete
Code used is EDMA_CHA_GPINT2 for COMPOSITE video output
and EDMA_CHA_GPINT3 for VGA output. For COMPOSITE, the
EDMA channel used is the channel 5 (which correspond to
external interrupt 5) and for VGA the channel 6 (for
external interrupt 6)
Could
you explain me which are video format used with
IEKC64x/NVDKC64x ?
Video input or output
format on IEKC64x board is in UYVY 4:2:2 format which is
probably the most popular of the various YUV 4:2:2
formats.
So each pixel is coded on
16 bits. The byte ordering used on IEK/NVDK is :..
|
Y0
|
U0
|
Y1
|
V0
|
Y2
|
U2
|
Y3
|
V2
|
Y4
|
U4
|
Y5
|
V4
|
...
|
The AGL library
delivered with the SDK allows you to quickly convert
this pixel format to planar format.(and vice versa)
So you can use IYUV (Planar 4:2:0) format with your
algorithm. This format comprise an NxN Y plane followed
by (N/2)x(N/2) U and V planes :
Luminance plane :
Chrominance U plane :
Chrominance V plane:
IEKC64_init()
returns error code <0x80130004>
This problem appears when using IEKLIB v1.3.x on
some board which are configured in stand-alone mode.
This will be corrected with v1.4. However, there is a
workaround to this problem : Even if you are using the
board in stand-alone, configure the dip-switch for PCI
operation (check User's Manual or Getting Started
Guide). Note that this will only prevent the DSP to
bootload from flash, but for CCS usage, it will remains
transparent.
|
