Dear colleagues,
I am testing an application on a DM6446 EVM. The app does not
use an OS. Part of it runs on the ARM size, another runs on
the C64+ side doing some additional processing. Basically, the
application loops back PAL video stream and not quite often
should overlay a resized frame over the vwindow0 - I am planning
the resized frame to go into the vwindow1 - where it would stay
still until vwindow1 is turned off.
I have been doing several trials to resize a full frame (two fields)
of interlaced video (PAL 720x576 YUV 4:2:2). Input data are fed to
resizer directly from CCDC.
Certainly, I have to rearrange the resizer output to get a progressive
frame for the VPBE display, but that's not a problem.
So far, I've made the resizer to down-sample a progressive frame
that is input from DDR2. When the input is CCDC there is a problem:
the first (top) frame is down-sampled just fine. The second (bottom)
field (all its scanlines) looks rotated and split horizontally.
A sample scanline could be illustrated as follows:
+-------+-----+---------------------------------+
| 1 e| 2 |s 3 |
+-------+-----+---------------------------------+
--> --> --> direction of rotation
The scanline begins at 's', ends at 'e'. 3 is shifted scanline,
1 is rotated end of scanline. Interestingly, region 2 exactly
corresponds vertically to the top (odd) field. Looks pretty
weird, isn't it... I have inspected two fields by using
different settings of VPBE and copying the resized frame in
order to arrange two fields for display. I also pretty sure
that the problem is not in the copy software.
Here are the questions: is it even possible to resize two fields
of an interlaced frame in one run of the resizer, provided that
the resizer input is CCDC module? Or does it indicates that I've
got incorrect settings, e.g. in the filters' coefficients or
resize ratios?
The user's guide states that the resizer uses internal syncs
if the resizer's input is CCDC, but the guide does not discuss
the algorithm of how the resizer processes two fields of an
interlaced frame. Could the internal syncing to be the reason
of rotated scanlines in the second field?
Actually, I even am not sure at which field (odd or even) the
resizer begins processing with.
Not that it is absolutely necessary to input a frame to the
resizer from the CCDC, instead of resizing data in DDR2, but
this is a matter of understanding things correctly.
Thanks for any information, I appreciate it very much.
Regards,
Andrew