• State Resolved
  • Locked Locked
  • Replies 12 replies
  • Subscribers 100 subscribers
  • Views 1357 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.

Netra Scaler to V4L2 Display Driver Buffer Compatibility

Dave Helsley1
Prodigy 230 points
Hello,

I am building a video decoding program similar to the decode_display demo program, only with the V4L2 driver at the back end.

The video chain is:



Buffer sets 1 and 2 in the figure above are allocated with calls to OMX_AllocateBuffer when initializing the IL client for the H.264 Decoder OMX module. The Scaler OMX module's client calls OMX_UseBuffer with buffer set 2. The problem I am having is what to do with buffer set 3.

If I allocate the V4L2 Display's buffers with VIDIOC_REQBUFS and OMX Scaler's output buffers with OMX_AllocateBuffer  all is good. Unfortunately, I must copy the 1920x1080x2 bytes per frame and this is hampering performance. I have done this, and I do see the video on the display.

If I allocate the V4L2 Display's buffers with VIDIOC_REQBUFS and then try to use them when initialing OMX Scaler's buffers with a call to OMX_UseBuffer, I get a segfault inside OMX_UseBuffer. It seems that OMX_UseBuffer only works on buffers that have been allocated with OMX_AllocateBuffer.
Has anyone else tried to hook this up before?
  • 0
    Prodigy 230 points

    More info:

    It seems I was actually getting a NULL pointer back for the OMX_BUFFERHEADERTYPE which caused the segfault. OMX_UseBuffer returns the error OMX_ErrorUndefined.

    The underlying problem remains, however, on how to get OMX_UseBuffer to accept a foreign buffer allocated by the V4L2 driver.

    Attaching log file in case there's useful info there.

    6153.log.txt

  • 0 in reply to Dave Helsley1
    TI__Mastermind 20245 points

    Hi,

    You should be allocating buffers from openmax using shared region and passing those buffers as userPtr buffer to V4L2 display. This will be much simpler to do.

    Regards,

    Hardik Shah

  • 0 in reply to HardikShah
    Genius 3120 points

    Hi,

    As Hardik said, Shared Memory (from Region #2) is the solution in this case.

    If you need any reference check this thread http://e2e.ti.com/support/embedded/linux/f/354/p/202453/723882.aspx#723883

    Regards,

    Krunal

  • 0 in reply to Krunal Patil
    Prodigy 230 points

    Krunal & Hardik,

    Thank you very much for your responses. I allocate the display buffers using OMX_AllocateBuffers. How can I be assured that they are from Shared Memory Region #2?

    I have done as you suggested and managed to get video output to work, with some stability issues to be resolved. I'm wondering if the instability could be due to being in the wrong region.

    Regards,

    Dave

  • 0 in reply to Dave Helsley1
    TI__Mastermind 20245 points

    Hi,

    What type of stability issue are you facing. Are you seeing some sort of crashes or hangs.

    Regards,

    Hardik Shah

  • 0 in reply to HardikShah
    Prodigy 230 points

    All of the above. I am attempting to ascertain the cause.

    If there are any known issues re: the stability of either the V4L2 display driver or the ALSA audio playback driver, please let me know.

    I did notice an apparent improvement in display stability if I paced out the video; i.e., not play it back at maximum speed, almost as if the display module could not handle it if the video was being passed in too fast.

    The audio driver seems like it may be hanging in an underflow condition; if there is insufficient data in the ring buffers, it's almost like it hangs and must be reset to work properly again.

    These are all preliminary observations at this point, yet to be proven out.

    On the video side, I see this sometimes:

    VPSS_FVID2: contrl event 0x6 timeout
    VPSS_FVID2: contrl event 0x10040018 timeout
    VPSS_DCTRL: failed to get node input status

    On the audio side, I get the "Could not write to audio device" failure, possibly indicating a buffer overrun.

    Thanks,

    Dave

  • 0 in reply to Dave Helsley1
    Prodigy 230 points

    I neglected to mention that at first I get the message:

    VPSS_FVID2: queue timeout

    Followed by

    VPSS_FVID2: contrl event 0x6 timeout
    VPSS_FVID2: contrl event 0x10040018 timeout
    VPSS_DCTRL: failed to get node input status

    after a while when the video part locks up.

    Does this offer any clues?

    Thanks,
    Dave 

  • 0 in reply to Dave Helsley1
    Genius 3120 points

    Hi,

    Let me guess, you might be using ezsdk version 5.03. This is the know issue in the VPSS driver.

    You can use patches available on this thread on top of ezsdk kernel: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/186865/675787.aspx

    Check if it works for you as well.!

    Regards,

    Krunal

  • 0 in reply to Krunal Patil
    Prodigy 230 points

    Hi Krunal,

    Actually, I have transitioned to 5.04, but I will look into the link you provided. At first glance, it seems to be intended for the V4L2 capture driver.

    Thanks,

    Dave

  • 0 in reply to Dave Helsley1
    TI__Mastermind 20245 points

    Hi,

    Yes, if you are getting this from display than those patches won't help. But we have never seen such issue. What are you exactly trying to do. Are you doing some run time parameter update on Grpx(fbdev) and you see this.

    Regards,

    Hardik Shah

  • 0 in reply to HardikShah
    Prodigy 230 points

    Hi Hardik,

    It looks like the stability may have been related to the number of buffers I was using, but it's difficult to be sure. When I reduce the number of buffers between the scaler and the display module from 8 down to 3, stability seemed to improve. Is this expected?

    At run-time in the core loop, it's nothing fancy. Not sure what Grpx(fbdev) is. If it's Gstreamer, we're not using it.

                // Pull element out of the display queue

                if (ioctl(disp->fd, VIDIOC_DQBUF, &disp->bufs[i]) < 0)
                {
                   DBGPRINTEX(g_hDbg, DBG_LEVEL_ERROR, "VIDIOC_DQBUF failed\n");
                }
                // Apply video frame pacing...
                
                // Put it back in
                disp->bufs[i].length = element->nFilledLen;
                if (ioctl(disp->fd, VIDIOC_QBUF, &disp->bufs[i]) < 0) 
                {
                   DBGPRINTEX(g_hDbg, DBG_LEVEL_ERROR, "VIDIOC_QBUF failed\n");
                }
    Dave
  • 0 in reply to Dave Helsley1
    TI__Mastermind 20245 points

    Hi,

    I think stability issues will be because you may  not be queuing buffers with proper index. You may  be queuing same buffers twice or thrice. Please check code for that. Stability should not be because of more number of buffers. With 3 buffers you may not get 60FPS, if you are pumping data at 60FPS you frame will reduce to 30 or 45 with less buffers. Check display FPS as done in sample code to make sure FPS is not getting dropped because of less buffers.

    Regards,

    Hardik Shah