• State Answer Suggested
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 577 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.

DM365 frame rate decimation from 30 Hz to 15 Hz

JayVee
Prodigy 180 points

Hi, we're using the DM365 processor to capture live 1080i video at 30 frames per second, but the DM365 is transmitting this video at 15 frames per second. We're trying to find out why the DM365 is decimating the frame rate. Here is what we know so far: The capture system is indeed capturing at 30 FPS but somehow the VPBE is making the driver run at 15 FPS. We're checking all the registers in the VPBE. The code uses a library call getDisplayBuffer() in the display thread to get a free display buffer. This is where the bottleneck is happening. If we measure the capture thread rate it is running at 30 FPS as it should. Does anyone know how to get the DM365 to transmit 30 frames per second when it is capturing video at 30 frames per second?

Thanks,

JV

  • 0
    Expert 2995 points

    It is need to fix VPFE ISR to pass both fields.

  • 0 in reply to Constantine
    Prodigy 180 points

    Thanks Constantine! It does look like the interrupt code is the culprit.

    JV

  • 0 in reply to JayVee
    Intellectual 485 points

     

    I am not sure which version or reference design u r using.

    In appro ipnc design there is a limitation in the driver itself. 

    The driver code is listed below.

    DMS365PrivatePackage/Application/src/av_capture/framework/drv/usermod/src/imgs_MT9P031_5MP/drv_imgsCalcCfg_MT9P031_5MP.c:

      if(dataW*dataH >= 1920*1080) {
        if(fps>24)
          fps = 24;
      }
      if(dataW*dataH >= 2048*1536) {
        if(fps>15)
          fps = 15;
      }

     

    Generally if you are having EVM or other designs then:

    I assume u loose the frame during the encoding.

    Even if u increase the frame rate, the priority of encoding  is very high, so you will miss frame capture during the encoding.

    There is any no use to capture the frame, if  u r not able to encode it.

    The thread priorities  can be of help for u here.

    Regards,

    Mahendra kumar

     

     

     

     

     

  • 0 in reply to mahendra kumar
    Prodigy 180 points

    Thanks for the info. In this particular mode our application isn't encoding video, merely passing it through from input to output. It looks like the video is being captured at the correct frame rate, but the display thread is only transmitting it at a decimated rate.  Here's what we know so far:

    The capture front end is working normally. We put a debug bit in the capture get and put functions inside the capture thread and it indeed runs at 30 FPS. The way the code works is after we call the Capture_get() function it returns a buffer with the current frame, and then writes it to a fifo using the FIFO_put() which the display thread is pending on. If we remove the FIFO_put() from the Capture thread it runs normally. If we enable the FIFO_put then once the FIFO fills up (32 deep) it will block the Capture thread until the Display thread unloads one pointer from the FIFO, decimating the rate at which the Capture thread would normally run, making it run at 15 FPS.

    So it appears as though the Display thread is being triggered to redraw at the frame rate, not the field rate. What triggers the Display thread to redraw? Does this trigger come from the VPFE ISR function mentioned by Constantine? Also, do the limits in the encoder driver mentioned by Mahendra somehow affect the redraw rate of the Display thread when video is just being passed through the system without encoding?

    -JV

  • 0 in reply to JayVee
    TI__Mastermind 19985 points

    JV,

    Display thread is governed by VPBE ISR and not VPFE ISR. We need to check the setup of display thread and the configuration you have done for display. Can you please test display separately. You can put one YUV data on the DDR and just turn on the display. By measuring the VSYNC frequency, we can make out if it is running at 30fps or not.

    Looking at the function calls you mentioned, you would not be using IPNC. If yes, then Mahendra's suggestion is not valid for your usecase.

    Regards,

    Anshuman