DM6446 VPFE Frame Resolution Support

Bt.656 standard  specifies NTSC/PAL timing; if you deviate from these timing requirements, you are no longer Bt.656 compliant.  If you want the flexibility to specify your own video timing requirements, you should use the YCbCr input mode along with HSYNC, VSYNC, and FID (the latter three normally found in SAV, EAV packets in BT standrads); of course this requires additional   HSYNC, VSYNC, and FID pins.

Thanks Juan,

So I can keep EAV,HorizontalBlanking,SAV,ActiveVideoData(For the desired resolution) for Horizontal Lined Data and generate HSYNC accordingly. Keep the number of blanking lines required for progressive and insert the video data lines and generate the VSYNC accordingly. Hope that the rasizer in the VPFE can accept this costum format. Will this be OK?

You can configure a few video input modes(RAW, YCbCr, BT.656) but all are mutually exclusive; therefore you cannot send timing signal via BT.656 interface (SAV, EAV...) and also have a separate HSYNC signal... as the hadware will look for video timing information in only one place depending on what input mode is configured.

What input resolution are you working with?  what video resolution do you want to resize to?  If you can provide this information, we should be able to verify if hardware resizer can support these...

The input resolution will be upto 1600x1200. We need to resize it to NTSC(525) or PAL(625) standard format. 

I will eloborate the requirement. The input to the FPGA connected to the DM6446 is YCbCr 4:2:2 16 bit data at 60 frames per second, 1600x1200 max resolution in ITU 1120 standard. The frame dropping is done from the FPGA to make it 30 fps or 25 fps for generating either NTSC/PAL as per the requirement. There may be cropping of active video if required. Now my doubt is what type of input format need to be generated and given to VPFE for doing the resizing to 525 lines or 625 lines. Since the input is in ITU 1120 standard i cannot give the frame directly. Can you give me th options and required method?   

A video iamge is made up of data (e.g. YCbCr pixels) and video timing signals (HSYNC, VSYNC, FID).  BT.656 and BT.1120 standards pass both of these via data bus eliminating the need for connecting additional pins and potentially saving boards space.  Generic YCbCr video input requires separate pins for the video timing signals.  When it comes to video timing signals (defines frame size and refresh rate), normally one device is the master and one is the slave thus ensuring both devices are speaking the same language.  I say normally, because you can have both devices being the master (ignoring video timing info coming from other device) but this will likely yield many more headaches as you will spend time tweaking timing signals on both sides to ensure they are talking the same language as small variations on how devices generate these signals internally can lead to headaches.

As you know, DM6446 does not support BT.1120 video input, hence the FPGA is a useful alternative to converting this signal to a generic YCbCr video input.  However, in addition to having FPGA take care of dropping the frame rate from 60 fps to 30 or 25 fps I would suggest it also needs to provide the video timing signals (HSYNC, VSYNC, FID) to DM6446, perhaps by simply reading the codes embedded in the BT.1120 stream and using them to toggle corresponding pins in FPGA.   This will ensure video coming from FPGA and recived by DM6446 is synchronized.

Alternatively, you can have the DM6446 generate its own video timing signals, but then one could argue your would not need FPGA; you can simply input BT.1120 signal to DM6446 and tell DM6446 it is a generic YCbCr signal; then you can configure DM6446 as a master when it comes to video input timing such that it defines HSYC, VSYNC, FID.. the internal video timing signals, if properly defined, should take care of having DM6446 ignore anything but the valid video data coming from BT.1120 stream (e.g. SAV, EAV codes...).  This means that it will capture all 60 fps of the BT.1120 stream, but you do not have to resize all of them; for example, you can choose to resize every other frame in your user application, yielding a final video output after resizing of NTSC @ 30 fps.  This is a riskier approach though, so I would go with the first one to avoid head-aches.

Finally, have you considered our DM365 platform ( http://focus.ti.com/docs/prod/folders/print/tms320dm365.html)?  It can support BT.1120 input and do the resizing, possibly eliminating the need for FPGA altogether.

Dear Juan,

The format of the output from the FPGA and the current picture that we able to see is also attached. We are not giving any valuble data during the HSYNC and VSYNC inactive period. Only the active pixel data, Y CbCr data, is passed to the DM6446 during the HSYNC and VSYNC low period(Active Period for us). Will you please check the attached files and please help me out what could be the possible reason that the video is seen like the first half portion on the right and second half portion in the left, or in the begginning. The data to the DM6446 is fed with 30 fps. The image shown in the attachment is just an example.

Regards,

Pavithran