Resizer capability question

John,

Can you clarify if you are getting error from codec or resizer driver ? I believe the later one.

regards

Yashwant

I'd say the resizer driver.  I'm calling the DMAI resizer routines.  I changed the capture driver to chain to the resizer and give me interlaced 420 frames.  I have to use the resizer in chained mode because the codecs all require 420semip video on input.  But I want to use the resize again at the application level to resize the frames for smaller resolutions.

It costs too much horse power to convert the full std res streams to 420 at the application level.  That's why it's chained in the driver.

JohnA

Anyone have any knowledge on how to set up the DM365 capture driver to use the resizer B to get a second image out?

JohnA

John,

I thought we had discussed in detail on how to get YUV420 output from both resizers in chained or non-chained mode. Basically, if resizer is connected in chained mode, we cannot create another instance of resizer and use it in memory-to-memory operation. But in chained mode also, you should be able to enable RSZB and have YUV420 output. The only limitation that you will have (and i think you already overcome it) is that the driver today uses only one field and scales it to a frame (so called deinterlacing).

If you are using DMAI, you can enable RSZB output using the following code

Int Resizer_continuous_config(void)

{

................

  rsz_cont_config.output1.enable = 1;
  //  rsz_cont_config.output2.enable = 0;

 rsz_cont_config.output2.enable = 1; //You need to set the parameters for output2 as are being set for output1.
    rsz_chan_config.len = sizeof(struct rsz_continuous_config);
    rsz_chan_config.config = &rsz_cont_config;
    if (ioctl(rsz_fd, RSZ_S_CONFIG, &rsz_chan_config) < 0) {
        Dmai_err1("Error in setting resizer configuration (%s)\n",
            strerror(errno));
        close(rsz_fd);
        return Dmai_EFAIL;
    }

.............

}

Hope this helps.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Anshuman Saxena said:

John,

I thought we had discussed in detail on how to get YUV420 output from both resizers in chained or non-chained mode. Basically, if resizer is connected in chained mode, we cannot create another instance of resizer and use it in memory-to-memory operation. But in chained mode also, you should be able to enable RSZB and have YUV420 output. The only limitation that you will have (and i think you already overcome it) is that the driver today uses only one field and scales it to a frame (so called deinterlacing).

If you are using DMAI, you can enable RSZB output using the following code

Thanks JohnA

Whoops I see a problem.  I need to change the RSZB to be active when in chained mode.  I won't be able to get a resizer handle to call it from DMAI.  I need to enable it from the driver I'm guessing.  That's where I need to know what to change.  I was unable to find it so far.  In fact I can't even find how it enables RSZA.  I.E. I can't see where output1.enable gets set to 1.

JohnA

John,

We dont need any changes in driver for enabling RSZB. It can easily be done by the change i mentioned. If you refer to the VPFE Driver user guide, you can see that the output of RSZB is on the same buffers, following the output of RSZA. So you dont need any extra handle. Once you enable RSZB in the code, both resizers work in chained mode and give two distinct outputs.

RSZA is enabled inside the driver for continuous/chained mode. This is because it is expected that RSZA has to dump out data in chained mode and if driver does not do it, user might miss this setting. But RSZB can be enabled separately from user space by the code snipped i mentioned.

Regards,

Anshuman

PS: Please mark this post as verified, if you think it has answered your question. Thanks.

Won't I get a "multiple instances not allowed" if I try to get a file handle for the resizer, when the resizer has already been opened by the capture driver in chained mode?

JohnA

I think I get it now.  The Capture code in the DMAI is opening the resizer and that's where I need to focus my efforts.

JohnA

The structure rsz_output_spec has a member called "pix_fmt".  The comment claims it must be UYVY, but I need the output to be YUV420.  I'm currently outputting YUV420 from RSZA.  Can RSZB also output YUV420?

JohnA

John,

You dont need a different resizer handle for RSZB. Basically, it is single resizer handle that gives out two outputs (from RSZA and RSZB). Once you enable the output2 inside DMAI code, you should be good to get two different outputs.

Regards,

Anshuman

Yes, you can output YUV420 from RSZB. You can set exactly same parameters like you are doing for RSZA.

Regards,

Anshuman

I modified the DMAI Resizer_continuous_config to enable the RSZ_B.  I added these lines...

rsz_cont_config.output2.enable = 1;

rsz_cont_config.output2.width = 352;

rsz_cont_config.ouput2.height = 240;

rsz_cont_config.output2.pix_fmt = IPIPE_YUV420SP;

When the call from Capture_get returns, the number of bytes used in the buffer is only enough for a 736x480 1.5 bytes/pixel image.  Is this because the bytes used ignores the extra smaller frame at the end?  Or is it not getting the second resizer image?

JohnA

John,

Do you mean v4l2buf.bytesused returns 736x480x1.5?

Regards,

Anshuman

Yes

I've got another issue now.  I am getting the second image in my frame buffer.  And the bytes used only reflects the RSZ_A image  My problem is that I'm getting both images but the chroma is messed up.  I'm getting corrupted chroma in the RSZ_A and RSZ_B image.  I've check the value of the second_off and it's the correct 529920 (736x480x1.5).

What has me concerned is that I am capturing interlaced and I just want the RSZ_B image to contain data from the top field.  So in the bottom field interrupt I only update the address for the RSZ_A image to get the second field.  I'm concerned that the RSZ_B resizer will run in the bottom field and corrupt the chroma of the first field.  I don't know if it's running, running and restarting at the original base address, or running and using the address at the end of the luma in the first field.

But that doesn't explain the corruption of the chroma in the RSZ_A image.  The buffer I'm creating is big enough for a PAL image so it's over 800K.  I doubt that even if the RSZ_B was tacking the second field on after the first it would overwrite past the end of the buffer.

The bottom line is I'm getting the luma for both images correct.  The chroma on the top half of the RSZ_A is messed up.  You can tell RSZ_A has the correct chroma but it's being overwritten in the top half.  The RSZ_B has what appears to be the correct chroma for the bottom half in the top half.  And the chroma in the bottom half is mostly black and white with some green glitches.

JohnA

In the resizer driver components, what's the difference between mem_param and ext_mem_param?  I'm pretty sure some of the registers aren't getting set correctly, but it's difficult to trace through the driver code to figure it out.  Since I'm not setting up hardly anything at the application level before calling the resizer driver, I can't tell how things are computed.

JohnA

I ran into a different problem now.  In preparation for my buffer to contain both images I made is larger like this... 

bufSize = ((736*576*3)>>1) + ((384*288*3)>>1);

vs the older method

bufSize = BufferGfx_calcSizeDim(&gfxAttrs.dim,gfxAttrs.colorSpace);

The buffer size increased from around 500K to 801792.  Which is the largest possible image if I'm running PAL with a D1 and CIF capture.

With no other changes my encoded image now has a red tinted chroma on alternating lines.

JohnA

John,

Can you share the complete YUV420 buffer including the output of both resizers? I would like to see if there is a problem with the line offsets etc. Also, if possible, please share the RSZ register values as well.

Regards,

Anshuman

John,

Good to know that your code works now. It would help if you could share some details on what exactly was the issue and how you fixed it.

Regards,

Anshuman

Hi Saxena:

     We are working on the DM368 resizer module. We are able to have resizer B worked and obtain resizer B's output. My concern is about the output of resizer A under continuous mode. Under the existing driver, the output config of resizer A is called "part_out_spec" in which the output dimension is not allowed to configure. That means the output of resizer A is alway 1:1 without any re-scaling functionality. It is not clearly mentioned at the existing documents.

     We can have the resizer B working at the re-scaling mode, but it has limitation of 1088 pixels/line.

     In addition, if working at continuous mode, the preview enging has output limitation of 1280 pixels/line. Am I right?

     Thanks.

Jerry