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
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
Please mark this post as answered via the Verify Answer button below if you think it answers your question. Thanks!
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
Krunal
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.
Dave
What type of stability issue are you facing. Are you seeing some sort of crashes or hangs.
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 timeoutVPSS_FVID2: contrl event 0x10040018 timeoutVPSS_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,
I neglected to mention that at first I get the message:
VPSS_FVID2: queue timeout
Followed by
after a while when the video part locks up.
Does this offer any clues?
Thanks,Dave
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.!
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.
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.
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
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.