On-the-fly Resizer directly from CCDC supported on DM6437?

Thanks a lot.

But it turns out that dealing with the registers is no easy task. It always gives me some mysterious results.

Anybody got the same issue?

I haven't set up the resizer to work directly from the ccdc, but I did do a memory to memory resize using direct register access, and it was certainly confusing to set up.

Hi, Matt,

Would you please share the register setting for the resizer?

I am trying to set it up for 720x480 -> 360x 240:

    VPFE_RESZ_RSZ_CNT = (0 << 29) | // CBILIN:
                        (0 << 28) | // INPSRC: input source
                        (0 << 27) | // INPTYP: input type
                        (0 << 26) | // YCPOS:
                        (0 << 23) | // 0x3 VSTPH(25~23): vertical starting phase
                        (0 << 20) | // 0x3 HSTPH(22~20)
                  (0x1fd << 10) |// 0x201 << 10 | // VRSZ(19~10): vertical resizing value
                  (0x209 << 0);  //0x201 << 0;   // HRSZ(9~0)
                   

    //VPFE_RESZ_OUT_SIZE = 0x00e80160;//352*232  
    VPFE_RESZ_OUT_SIZE = (0x120 << 16)             //  output height 0x120=288
                                             |(0x170 << 0);

    VPFE_RESZ_IN_START = 0x0;//0x100010; //16 pixels and 16 lines offset  
   
    //VPFE_RESZ_IN_SIZE  = 0x01d002c0;//704*464
    VPFE_RESZ_IN_SIZE     = (ih << 16) | (iw);

    VPFE_RESZ_SDR_INADD = 0; //0x82000000;  
    VPFE_RESZ_SDR_INOFF = 0;//0x580;  
    VPFE_RESZ_SDR_OUTADD = DisplayBuf;  
    VPFE_RESZ_SDR_OUTOFF = 0x2c0;

Thank you so so much for the detailed guidance.

I didn't put the whole thing there. But I did missed some of what you mentioned here. I will make some modifications and re-upload the settings.

I am looking forward to the further discussion.

Mike

Michael16880 said:

Thank you so so much for the detailed guidance.

I didn't put the whole thing there. But I did missed some of what you mentioned here. I will make some modifications and re-upload the settings.

I am looking forward to the further discussion.

Mike

 

To answer some of these:

1) It's not shown here, but I will upload them later.

2) I will recalculate everything.

3) Yes, DisplayBuf is 32-byte aligned

4) Data directly from CCDC for now, but eventually will be from the preview engine.

5) What are the crazy constraints mentioned here?

Thanks a lot for the step-by-step checkup.

5) If you look in spru977d, section 5.6.6, make sure you meet all the listed constraints.  The tricky part is table 26, especially when you are chaining the ccdc->previewer->resizer together, you have to make the output/input sizes between modules EXACTLY right, or the whole thing will fail.

Thanks a lot. I see what you mean.

Right now I have ccdc-> resizer since I use a DVD as the testing input. Eventually I will have a video sensor and ccdc->preview-> resizer.

Made some progress with your suggestions and I will upload what I have a moment later. Really appreciate your help.

Here is the procedure I followed. I made some progress but not good enough. Right now the input frame is resized to 1/4 height rather than 1/2, and the left-top corner of the resized moves in both x and y directions in the video window 1.

My task: resize input frame 720x480 to 360x240.

Hardware: ccdc -> resizer -> sdram

Steps:

1) Use the Linux calccoef to obtain:

  hrsz = 510

  vrsz = 509

  all the 32 filter coefficients for both vertical and horizontal

  So the resizer should use the 4-taps & 8-phases

  So far I assume: in_width = 720, in_height = 480 & ow= 360, oh= 240

2) Calculate iw & ih using 4-tap Eq. (9), sph = spv =0

  iw = 722.25

  ih = 479.26

  So I use iw=722 & ih =479

3) The code for the resizer:

    VPFE_RESZ_RSZ_CNT = (0 << 29) | // CBILIN:
                                              (0 << 28) | // INPSRC: input source
                                              (0 << 27) | // INPTYP: input type
                                              (0 << 26) | // YCPOS:
                                              (0x0 << 23) | // 0x3 VSTPH(25~23): vertical starting phase
                                              (0x0 << 20) | // 0x3 HSTPH(22~20)
                                              (0x1fe << 10) | //vertical resizing value
                                              (0x1fd << 0);    // HRSZ(9~0)
                   
    VPFE_RESZ_OUT_SIZE = (240 << 16) | (360);
                       
    VPFE_RESZ_IN_START = 0x0;   
    VPFE_RESZ_IN_SIZE     = (479 << 16) | (722);

    VPFE_RESZ_SDR_INADD = 0;     // For input from CCDC or Preview: INADD = 0, INOFF = 0
    VPFE_RESZ_SDR_INOFF = 0;   
    VPFE_RESZ_SDR_OUTADD = DisplayBuf;  
    VPFE_RESZ_SDR_OUTOFF = 736;

    VPFE_RESZ_HFILT10   = (horz_coefs[1]  << 16) | horz_coefs[0];  

   ....

4)  OSD Video window 1 display

The video window 0 displays the input frame and it's working fine. The video window 1 has been testing with a pre-load static image 384x240 and it's working fine

Here are the config for the current settings.

    VPBE_OSD_VIDWIN1OFST = 736>>5;                                    
    VPBE_OSD_VIDWIN1ADR = bufferResz;
    VPBE_OSD_VIDWIN1XP  = 1;        // if 0, then a lot of noise on the right side!!! =1 solve all the problem Weird
    VPBE_OSD_VIDWIN1YP  = 0;
    VPBE_OSD_VIDWIN1XL  = 360;
    VPBE_OSD_VIDWIN1YL  = 240>>1;

Several observations:

1) If vid window 1 is NOT enabled, video window 0 is working fine. But when vidwin1 is on, then the top half of vidwin0 is shifted left for a few pixels.

2) VPBE_OSD_VIDWIN1XP = 0. Some display will show up on the right-top side with trash data. As long as VPBE_OSD_VIDWIN1XP>0, the trash data is gone.

Questions:

1) On some post, Paul.Yin mentioned:

RSZ_CNT.HRSZ = hrsz-1

RSZ_CNT.VRSZ = vrsz-1

Does it mean I have to use 509 & 508 instead?

2) The resized looks like compressed into 1/2 height. Is it possible that problem comes from interlaced field issue?

Thanks a lot! Any input is appreciated.

Gosh, I wish the TI driver could support on-the-fly mode!

First, yes, you should load (hrsz-1) (vrsz-1) into the register fields.

Second, you are getting the input from the previewer, but appear to be expecting more input pixels in the resizer than you will be getting.  If the previewer is outputting 720 pixels per line, the resizer will not be getting 723.  This is the boondoggle of matching the previewer output to the resizer input I mentioned eariler.  (I think) the previewer has to output values that are greater than or equal to the resizer input programmed values.  I ended up getting a 50% downsized image that was a few pixels smaller than half of the input image.  If your input width is constrained to 720, then you might have to output (360-x) but keep the line offset of 360 and live with the blank pixels.

I haven't fooled with any of the video port back end, so someone else will have to chime in to help you there.

Sorry for the confusion.

I am getting input directly from CCDC, NOT previewer. Even that, I am confused by the calculation results obtained from those equations.You are absolutely right about the size constraints.

I also tried with another parameter setting from a sample: with iw = 704 ih = 464 and ow = 352 oh=232. Same symptom.

Thanks a lot for the input.

How about you try a different tack.  Since you have a constrained input size, back calculate the appropriate output size.  You know the resizer "eats" 7 pixels off the input width from the equations in the table.  So set your output width to (720 - 7)/2 = 356.5, on second though make your input width 719 so you get a round 356 input out.  You can now punch those io widths into the calccoef utility.  Same approach for the height, you have to double check whether you need to lose 4 lines or 7 depending on the resulting resizer ratio.  Keep your resizer output line offset at the 360 pixel level.  Let me know if that works any better.

EDIT: now I'm not so sure about the input width of 719.  Try 720 if that one doesn't work.

Thank you for the suggestion.

May I know how to decide the number of  eating pixels? Are those equations of Eq.(11) and Eq.(9), supposed to calculate these?

Now I follow (720-7)/2 =356, if using 7 lines for the horizon: (480-7)/2 = 236.5

so I use ow = 356, oh = 236

calccoef: -i720x480 -o356x236

then hrsz = 514 vrsz = 515

plug them into Eq.(10) since 7-tap filters:

iw = (356-1)*514/256+7 = 719.7 so iw = 720

ih = (236-1)*515/256+7 = 479.75, so ih = 480

NO bad so far.

    VPFE_RESZ_RSZ_CNT = (0 << 29) | // CBILIN:
                        (0 << 28) | // INPSRC: input source
                        (0 << 27) | // INPTYP: input type
                        (0 << 26) | // YCPOS:
                        (0x0 << 23) | // 0x3 VSTPH(25~23): vertical starting phase
                        (0x0 << 20) | // 0x3 HSTPH(22~20)
                 (0x202 << 10) |
                  (0x201 << 10);
                   
    VPFE_RESZ_OUT_SIZE = (236 << 16) | (356);                        
    VPFE_RESZ_IN_START = 0;      
    VPFE_RESZ_IN_SIZE =  (480 << 16) | (720);
    VPFE_RESZ_SDR_OUTOFF = 736; // 0x2e0;    // 0x2c0; // 2c0 = 704

The only thing is different from your suggestion is SDR_OUTOFF since I believe it must be multiples of 32.

Then I got a different results: This is getting interested. Similar to a previous post.

Did you ever manage to get this working?  I just got finished testing a project that uses the resizer on the fly and I'm getting good results.

Hi, Matt, 

Thanks for the reply. It's been a while, and I was busy with some family business and get back to this issue.

The best result I can get now is a resized image with 1/2 width but 1/4 height. My  resizer config:

VPFE_RESZ_RSZ_CNT = (0 << 29) | // CBILIN: 
						(0 << 28) | // INPSRC: input source, must be 0 if from CCDC
						(0 << 27) | // INPTYP: input type
						(0 << 26) | // YCPOS: 0: YC, 1: CY
					    (0x0 << 23) | // 0x3 VSTPH(25~23): vertical starting phase
					    (0x0 << 20) | // 0x3 HSTPH(22~20)
				 		(510 << 10) |//(0x1fd << 10) | vfactor << 10 | // 0x201 << 10 | // VRSZ(19~10): vertical resizing value 
				  		(511 << 0); //(0x1fc << 0); hfactor << 0; //0x201 << 0;   // HRSZ(9~0)
						// vertical/horizontal resizing value plus 1
						
    VPFE_RESZ_IN_START = 0;
    VPFE_RESZ_IN_SIZE  = (464<<16) | (704 << 0);

    VPFE_RESZ_OUT_SIZE = (232<<16) | (352 << 0);

    VPFE_RESZ_SDR_INADD  = 0;
    VPFE_RESZ_SDR_INOFF  = 0;

    VPFE_RESZ_SDR_OUTADD = reszBuf;
    VPFE_RESZ_SDR_OUTOFF = 704; 

The next post will show how the output looks like. I appreciate any input from you or others.