I have been quite busy since the last update trying various options for recording MJPG video using a Logitech QuickCam Pro 9000 and the Gumstix Overo Fire embedded computer. The good news is that there has been significant progress reported in the following sections.
Uvccapture
As I wrote in my last update I wanted to take a closer look at uvccapture and see if we can use it for capturing JPG encoded frames from the camera. This functionality is already available in uvccapture; however, it only works at low resolutions and max 1 fps. So I forked the source code from the latest release and made the following modifications:
- Allow capturing JPG at any resolution supported by the camera
- Support sequential file names (img00o.jpg, img001.jpg, …)
- Allow specifying the number of images to capture
You can check out my modified code from my repository at Github: http://github.com/csete/uvccapture. I didn’t do any formal implementation of the higher frame rates; however, I did try to let it record in free-running mode, i.e. as fast as it can go. Unfortunately, the highest frame rate I could achieve this way was around 15 fps.
Back to Gstreamer
Since the video recorder has to be on a rocket that accelerates very fast (6g or something like that), the 15 fps I could get with uvccapture was just not good enough. I want to get up to 30 fps. Before taking a closer look at how to increase the frame rate in uvccapture, I decided to take another look at Gstreamer – I found it hard to accept that it couldn’t capture usable JPG images.
After some experimenting I realized that all I had to do was to put the JPG frames into an AVI container and I had an AVI video file that could be played by both VLC and mplayer:
gst-launch v4l2src ! image/jpeg,... ! avimux ! filesink location="somefile.avi"
This is actually really amazing from a performance point of view. Since the camera does all the encoding, the host computer only has to mux it into AVI and save it to a file. CPU load on a desktop PC is hardly noticeable.
Gstreamer on the Gumstix Overo Fire
Next item on the agenda was to try the gstreamer pipeline on the Gumstix Overo Fire. The first round of testing was carried out using a slow microSD card. Not sure about its speed – class 2 I would guess. Using this card I could capture usable video up to 800×456 at 30 fps. Above that resolution the video was bad. You can see the test videos here: http://files.oz9aec.net/video/Gumstix/2010.09.20-mjpg/. CPU load was never above 10% so I figured the processing bottleneck must be either at the USB interface or at the microSD interface.
I got a class 6 microSD card and repeated my recording experiments with pretty much the same results: Good video up to 640×480 / 800×456 at 30 fps but not above that. See the test videos here: http://files.oz9aec.net/video/Gumstix/2010.09.21-mjpg/. This was quite disappointing since we wanted to capture high definition video. I did some further experiments in order to try and figure out where the bottleneck is, USB or microSD. What I did was to insert a videorate element between the v4l2src and the muxer and:
- Capture video at 10 fps and upsample it to 30 fps using the videorate element → Good video
- Capture video at 30 fps and downsample it to 10 fps using the videorate element → Bad video
From this I conclude that the bottleneck is at the USB interface end. I can rule out the camera and the USB hub, since both of them work fine when using them with a desktop PC, therefore I believe it is a Gumstix Overo issue.
This was bad news for the idea of using UVC camera with the Gumstix Overo COMs. I guess we will have to use the digital camera interface and hardware DSP encoding to get high definition. On the other hand, I am not sure that the OMAP3530 is at all capable of encoding 1280×720 but I do not know.
We had a brief discussion about whether we want to proceed with this given that we can not get better than VGA resolution, or to try something else e.g. an off the shelf camera. We decided to continue since even with only VGA resolution, this will be a step forward in the right direction and a significant improvement compared to existing systems.
The next days will focus on finalizing and testing the software recorder and also work on the hardware integration.