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.

unable to run gstreamer on pandaboard with OV5640 camera



Hello,

  I have OV5640 sensorn connected to pandaboard (ES2.2). I am using kernel from oamp4-v4l2-camera. It contains drivers from Sergio.

 I need to stream captured video over the network. To do this I am attempting to use GStreamer, which has worked very weel on other platforms, however I cannot get gstreamer to work on pandaboard with ov5460 sensor.

with gst-inspect --gst-debug=3 v4l2src I contineously get following warning:

                   0:00:01.414886418  4030    0x18050 WARN                    v4l2 v4l2_calls.c:264:gst_v4l2_fill_lists:<v4l2src0> Failed querying control 134222679 on device '/dev/video0'. (25 - Inappropriate ioctl for device)

I am not sure how to fix this.

Has anyone  been successfull to use gstreamer with OV sensor on pandaboard?

 

Thank you very much.

 

 

  • Does your gst plugin query the capability before issuing an ioctl? This is one of some basic requirements from a V4L2 client. Please note that OV5640 V4L2 driver  developed by Sergio supports just a bare minimum set of ioctls.

  • gst-plugin  v4l2src supports quiring the capabitilies.

    I cannot figure out what the gst-lauch command should be, since v4l2src is handled by omap4iss driver. I do not know how to like OV5460 driver to omap4iss driver via gstreamer.

    I can use yavta to capture images, but cannot use gstreamer.

    Can someone please help?

    Thank you

  • I have used the ov5640 to capture the images and encode video by the gstreamer command as below:

    sudo gst‐launch v4l2src device=/dev/video0 ! video/x-raw-yuv-strided,width=1280,height=720 ! videoparse format=yuy2 width=1280 height=720 framerate=10/1 ! ffmpegcolorspace ! ducatih264enc ! filesink location=./cam.mp4

    Note: The driver avaiable on www.gitorious.org/omap4-v4l2-camera/ doesn't implement some ioctls that gstreamer needs, so we extend the driver, and it can encode now. if you need more information, please email me.

     

  •  for the detail of using gstreamer to capture and encode video on pandaboard ubunu12.04 , see http://www.xfengche.com:8888/wp-content/uploads/2014/04/Pandaboard-Camera-Board-Manual.pdf. the camera board is avaiable on the store:

  • Hi Guohui,

    My colleague and I just received the OV5640 module (ordered from xfengche) today and gave it a try on our Pandaboard-ES Rev B3 running the stock panda image for Ubuntu 12.04.

    We can take photos using the commands in the manual, and see preview video without any troubles.

    Encoding video with the camera manual commands will produce a file, however we are having trouble playing it back. Totem (mplayer) will load the file and play it once at about 5x speed. Then, it cannot play again.

    Transferring the file to a Mac OSX machine doesn't help, as neither iMovie, Quicktime, or VLC media player can achieve any playback at all.

    Can you help us?

    Thank you!

    Jamie

  • HiJamie

          we fix the bug that results in the 5x speed when playing encoded video last week. the cause comes from the gstreamer encoding command:

         sudo gst-launch v4l2src device=/dev/video0 ! video/x-raw-yuv,width=1280,height=720,framerate=20/1 ! ffmpegcolorspace ! ducatih264enc ! filesink location=./cam.mp4

         because OMAP4 IVA-HD needs NV12 format, so we use ffmpegcolorspace to convert the captured video to NV12 format, but it consumes CPU to much extent, which results in encoding cann't reach 30fps.

         now we update the driver of OMAP4 ISS, and can use OMAP4 ISS to convert the captured data to NV12 format, so, it can encode 720p video at 30fps, the command is as below:

         sudo gstlaunch v4l2src device=/dev/video3 framerate=30 ! video/xrawyuv,width=1280,height=720,framerate=30/1 ! ducatih264enc ! filesink location=./cam.mp4

        the image that supports 720p@30fps is avaiable here:http://qd.baidupcs.com/file/41dd3155072801d9db88159e9474df2c?fid=1562824548-250528-104943415477835&time=1398148596&sign=FDTAXER-DCb740ccc5511e5e8fedcff06b081203-HVOQcnrBDW2x2xJBjLKVNPvFTAs%3D&to=qb&fm=Q,B,T,t&newver=1&expires=8h&rt=pr&r=157130722&logid=2339477574&vuk=1562824548&fn=img_ducati_4G.img.tar.gz

        in addition, it is recommend that you use mplayer to test the encoded video rather than QuickTime and iMovie. mplayer is avaiable on ubuntu12.04 on Pandaboard, and it will output the decoded video to HDMI monitor.

    note: mplayer has a parametere -fps to control the playing rate, it is efficient to test the framerate of encoded video.

  • Your quick reply is much appreciated. Thanks, Yang.

    We downloaded and tried the new image last night. We can get 720p@30fps now, but we are still having a few issues I hope you could help us with.

    1. At 720p@30 the output video recording file is much shorter than the full video capture time (less than half). At 480p, the full video is successfully captured.
    2. Now we get a black image when taking stills with capture.elf, and sometimes, capture.elf fails to load with the error msg "failed to setup/enable/activate link between OMAP4 ISS CSI2a output and OMAP4 IS CSI2b". Is that because /dev/video0 becomes /dev/video3 in the new kernel image? How to take still images with this new kernel image?
    3. In the previous kernel image, we could capture images with capture.elf, but they were fuzzy. In the docs, it says autofocus is supported both in capture.elf and the OV camera module, but we get the same out of focus level for all ranges of objects in the camera's field of view. Seems the focal point never changes
    4. 1080p (any fps) is not working, but it says it is a supported resolution in the docs. Does 1080p work on your side at any fps? Any recommended commands to get it working on our side?

    Thanks again for all your help!!

    Best,

    Jamie

  • Hi Yang,

    Correction to #4: 1080p works with the new kernel image. The playback of the recorded file is still half the recorded length, it is sped up similar to the 5x speed problem with 720p on the previous kernel image, and the video is zoomed and cropped to display the top left corner. We think the zoomed/cropped issue is due to the monitor resolution being 720p. What do you think?

    Best,

    Jamie

  • Very nice can help you! I check our docs and  find a serious bug. For your first problem, the code command should be 

    sudo gst‐launch v4l2src device=/dev/video3 framerate=30 !

    video/x‐raw‐yuv,width=1280,height=720,framerate=30/1  !    queue !  ducatih264enc  !  queue ! filesink
    location=./cam.mp4 

    for it is impossible capture rate  mismatches code rate so we can use the queue element to Cache it .
    For your second problem,the capture.elf  pipeline setting still to be cam->omap4 iss csi2a->omap4 iss csi2a out,but  now the pipeline should be cam->omap4 iss csi2a ->omap4 iss ipipeif ->omap4 iss isif ->omap4 iss resizer a out .So you can see the problem . I am very sorry for it ,I can send your new capture.elf by email . can you send your email to my email. My emai is www.yangjianjun1028@126.com .
    For your forth problem , it is not stable. When  it happen not work . you can retry it . Also it is impossible for your first problem rate mismatch.

  • Hi Yang,

    I sent a message to your email account--please let me know if you don't receive it.
    Thanks so much again for your very fast and thorough help. We have everything working on the video side to our satisfaction, and we are eager to see what your team can do with 1080p in the future.
    Now to the image side. From our TI discussion, it is clear where the problem lies in setting up the pipeline, and we'd like to get a copy of the new capture.elf executable.
    Lastly, do you have any suggestions on the autofocus issue I mentioned as #3 in the TI post? We can't see to activate the focus or see any focusing difference in the experiments we run. We'd like to get a sharp picture.
    Best,
    Jamie
  • Just a quick mention about a bug we noticed in encoding with the new kernel image as compared to the original kernel image. The bottom row of pixels is missing (a thin green line) and instead it has been copied over the top row of pixels.