We're using a custom daughter card with an 8168 to capture DCIM images over 1394b Firewire with gstreamer. Using the following (simplified) pipepline, I'm getting very low FPS (6 ish) and high CPU utlization (100%) on the default image size (1600x1200):
gst-launch dc1394src ! omx_noisefilter ! omx_h264enc ! gstperf ! filesink
If I remove the omx elements, my framerate hits the target of 15 fps and CPU utliization is minimal. I'm assuming the problem has to do with image capture on the A8 side using the dcim dc1394 driver and then copying it to the M3 VPSS side for encoding. Based on other posts (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/165788.aspx), it looks like the omxbufferalloc element can help with this issue by allocating the image frame in friendly memory space. If I blindly insert it into my pipeline:
gst-launch dc1394src ! omxbufferalloc ! omx_noisefilter ! omx_h264enc ! gstperf ! filesink
I get debug statements saying the buffers are allocated, but no images are pushed through.
Judging by the TI Gstreamer subversion logs, the omxbufferalloc element itself is not sufficient, and there were additional adjustments to V4L2src to make this work (addition of gst_v4l2_buffer_new_userspr in gstv4l2bufferpool.c). Can anyone provide confirmation that similar changes to the dc1394src element *should* be sufficient to take advantage of omxbufferalloc behavior?
Any other guidance on using omxbufferalloc for non-V4L2 sources?
Thanks,
Dave