With only two weeks left until the flight opportunity it was time to make status and try to assess how much I can finish until the launch.
The Gumstix Overo Fire has now been up and running for a about a week (not 24/7 though) and after a few rookie mistakes I am confident with the basics, i.e. how to prepare SD card, where to to put boot loader, etc. I have also been successful with using my Logitech webcams with the Gumstix Overo Fire, except when it comes to encoding videos or even single images. With the current installation everything runs on the ARM and this is just not fast enough to do any interesting encoding; maybe 320×240 jpeg image at 1 frame per second but seriously… In order to encode higher resolution and at higher frame rate I will need access to the hardware DSP via the TI Gstreamer plugins with DVSDK, DMAI and whatever other fancy names they have come up with. I have spent a few hours reading the instructions, which are of course spread over a few sites, and I am of course as lost as I possibly could be. Not to worry, I am sure that it will suddenly make sense if I just read the instructions long enough but I can not assume that it will happen anytime soon. Sometimes it comes after a day, sometimes after a month. Keeping in mind that I only have two weeks left where I can spend about 15-20 hours per week (I do have a daytime job) I think it was fair to postpone real-time encoding for a later project.
So what else can we do? I see three options left:
- Capture and save raw frames
- Capture and save MJPG video
- Capture and save JPG images at lower rates
Note that MJPG video and JPG images are more or less the same in that the MJPG video is a collection of JPG frames. How the frames are seprated I do not know and I doubt there is one universal standard for that. I tried to capture using a Gstreamer pipeline using the “image/jpeg” caps filter, but the result was unreadable by any app I have both when captured to a single “mjpg” file and when captured to single jpg images. I decided not to pursue this any further since there are other viable options for MJPG/JPG capture.
Using the command line interface of Guvcview I managed to capture an .mjpg file that I could play using both VLC and mplayer. Unfortunately, the guvcview GUI comes up even when cpaturing video in batch mode and I do not like that – I do not need any GUI when the Gumstix Overo Fire is running as a headless embedded computer.
I then tried uvccapture, which is an extremely simple app to capture JPG images from webcams. It works well and as expected but there are a few quirks that I will have to change:
- It can not use incremental file names (image000.jpg, image001.jpg …) instead, each newly capture image will overwrite the last one.
- It can only capture at max 1 fps.
- At resolution 960×720 and above it activates YUYV capture and uses external lib to compress JPG image. My Logitech webcams can deliver JPG image even at the highest resolution so I assume this is just a software limit built into uvccapture.
Fortunately, the code appears to be simple and straightforward and I don’t expect any problems with hacking it to suit my needs. The enxt few days will be dedicated to modifying uvccapture and to make it run on the Gumstix Overo Fire. It will also be interesting to see what frame rate we can achieve without using streaming mode on the webcam.
Finally, a few words about capturing and saving raw data. This can be easily achieved using a Gstreamer pipeline:
gst-launch v4l2src ! video/x-raw-yuv,format=YUY2,width=640,height=480,framerate=5/1
! multifilesink location=img%05d.yuv
Unfortunately, the raw files are very large, about 500 kB/frame at VGA resolution and between 3 and 6 MB/frame at 1600×1200 depending on the pixel format. Although I have an 8 GB microSD card for storing the images, I am not sure that the Gumstix Overo Fire can maintain a high enough throuput to the SD card. My card is Class 6 which as i understand is at least 6 MB/s and the package says even up to 15 MB/s, I am unsure whether the processor and the bus can sustain that transfer rate. I will have to measure it. Untill then, here are the frame sizes we have to deal with.
- YUYV (YUY2):
- 640×480: 614400 bytes/frame
- 1600×1200: 3840000 bytes/frame
- YV12 and YU12 (I420):
- 640×480: 460800 bytes/frame
- 1600×1200: 2880000 bytes/frame
- RGB3 and BGR3:
- 640×480: 921600 bytes/frame
- 1600×1200: 5760000 bytes/frame
- JPEG:
- 320×240: 7297 bytes/frame
- 640×480: 18583 bytes/frame
- 800×600: 25698 bytes/frame