• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 784 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using the Resizer with DM368?

John Anderson
Genius 5240 points

I'm having a problem trying to use the resizer on the DM368.  More specifically, I took the video_loopback_resize example app under DMAI, compiled it, and ran it on my board.  I get the following error...

davinci_resizer davinci_resize: 2

mode doesn't allow multiple instances

Failed to create resize job

My initial suspicion is that the vfpe-capture driver is opening the resizer and that's why the application fails.  I'm using the composite input and when I open the capture driver I get a message saying...

vpfe-capture vfp-capture: Resizer present.

Am I taking the wrong approach to use the Resizer?  It is not available when using the composite input?

John A

 

  • 0
    TI__Expert 5680 points

    John,

    Have you configured IPIPE in single-shot mode ? If not then use "dm365_imp.oper_mode=1" in the kernel bootargs to configure it in single-shot mode. DMAI resizer module works with single-shot mode only.

    Thanks

    Brijesh

  • 0 in reply to Brijesh Singh
    Genius 5240 points

    I gave that a try but I now get...

    davinci_resizer davinci_resizer.2: Operation mode doesn't match with current hw mode

    It seems that the dvsdk sample apps use EDMA to resize the picture without any pre-filtering and it looks bad.  So I'm trying to switch to using the Resizer.  I would have thought that video_loopback_resize would demonstrate what I want to do, but it won't work either.  I just need to find al the mystery parameters that must be set.  So any more advice is welcome.

    John A

  • 0 in reply to John Anderson
    Genius 3475 points

    Hi,

    In DVSDK/Dmai.../packages/ti/sdo/dmai/linux/Capture.c,  you  have to set  :    captureChainMode=FALSE.

    Regards,
    Marko.

  • 0 in reply to Marko Shink
    TI__Mastermind 19985 points

    Hi John,

    Replied to a similar thread on http://e2e.ti.com/support/embedded/f/354/p/84231/291532.aspx#291532

     

    Regards,

    Anshuman

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

  • 0 in reply to Marko Shink
    Genius 5240 points

    I didn't set captureChainMode to FALSE, but I set onTheFly = FALSE in the DMAI Capture_Attrs, along with setting dm365_imp.oper_mode=1.

    Now I can open the capture driver without chaining the resizer.  However the resizer was apparently needed to get the video mode to 420PSEMI.  So now I can't open my h264 encoder.  Do I now need to run my captured frame through the resizer to convert the video format to 420PSEMI?  Can I do this without the video being deinterlaced?

    John A

  • 0 in reply to John Anderson
    TI__Mastermind 19985 points

    Hi,

    John Anderson said:
    Do I now need to run my captured frame through the resizer to convert the video format to 420PSEMI?

    Yes, you need YUV420SP data format before giving it to H.264 encoder. You can do it using resizer driver.

    John Anderson said:
    Can I do this without the video being deinterlaced?

    Yes, now that you have set captureChainMode as FALSE, you would be getting YUV422 data in the memory from your capture device. This resolution would be 720x480 and hence no deinterlacing done. Now when you call resize operation, you can use this complete 720x480 frame of YUV422 data and just convert it to YUV420SP without any scaling. This will not drop any field or not do any deinterlacing.

    Hope this helps.

    Regards,

    anshuman

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

  • 0 in reply to Anshuman Saxena
    Genius 5240 points

    Anshuman Saxena said:
    Yes, now that you have set captureChainMode as FALSE, you would be getting YUV422 data in the memory from your capture device. This resolution would be 720x480 and hence no deinterlacing done. Now when you call resize operation, you can use this complete 720x480 frame of YUV422 data and just convert it to YUV420SP without any scaling. This will not drop any field or not do any deinterlacing.

    Anshuman,

    I now have the captured interlaced UYVY frames coming in at 720x480 resolution.  The problem I'm now having is getting the resizer to work.  The output 420 resolution needs to be 736x480 or Resize_config refuses to succeed.  So I set the output 420 buffer dimensions to 736x480.  Resize_config works but Resize_execute does not work correctly.  I actually sets the output 420 buffer user size to larger than the 420 buffer size.  i.e. the output buffer size is the same as the input UYVY buffer size.

    John A

  • 0 in reply to John Anderson
    TI__Mastermind 19985 points

    What do you mean by resize_execute not working? Have you set the output format correctly to YUV420SP? Also, for 736x480 limitation, you can set the pitch as 736 where as the line width can still be 720. This will ensure that you get a valid 720x480 image on a memory of 736x480 where last 16 pixels on each line is not valid data.

    Regards,

    Anshuman

  • 0 in reply to Anshuman Saxena
    Genius 5240 points

    I tried setting the width to 720 and the line length to 736 and the resulting image is bad.  It needs to be 736 for both.  Since I now have two threads on the same subject I guess we can forget about continuing in this thread.

    http://e2e.ti.com/support/embedded/f/354/t/95375.aspx