video under linux


I’ve found a library that provides a uniform interface to v4l, v4l2 and firewire devices under linux. It also brings a settings function that allows to change camera settings under linux.

It’s frequently updated (last version october 10 2007), has a complete api documentation an tutorial and it’s licensed under GPL.

It’s name is libunicap.

I think it can be a better choice for linux than directly using v4l.

Let me know if it can be interesting. If so, I can try to develop a grabber version for of using this library.

cool, it looks great!

the only downside I see for it is that is GPL, and we’ve been pretty hesitant to use GPL as part of the main codebase, because we don’t want to release OF under GPL (but rather, under a LGPL, or more permissive license). researching, however it looks like V4L is also GPL, so I don’t know how we can avoid these license issues on a linux distribution. Everything else we use is LGPL, so I guess people can just decide what they want to do and will figure out the license issues with linux. Our goal is to give the user the most amount of freedom with OF so that they don’t have to worry about modifying it, using it in commercial projects and so on.

If you’d like to get on it, which would be super, I’ll email you offline about the v0.03, which is on the svn, but I can provide you w / codeblocks and command line compiling versions…


I don’t think that GPL will be an issue with V4L as far as you are not distributing it with openframeworks, but it only have dependencies. Indeed libunicap has the posibility of a commercial license and it has dependencies with v4l.

If you think it’s allright, send me the svn repository data to my mail, and i’ll try to develop a version of the grabber using the library.


I have a working version of the video grabber using libunicap, I thought it will be more difficult than it actually was :). It’s based on the 0.02 version, but it works perfectly with the v4l and firewire devices i’ve tried.

I’ve created a ofUCUtils and added some conditional compilation to ofVideoGrabber so you can select between v4l or libunicap when working with linux: don’t know if that’ll make it easier to solve the licensing problem.

Some questions:

  • what is the expected behavior when the camera returns b&w frames?. I suppose that just converting them to GL_RGB, but just to be sure. And then, which is the fastest way to do that? I’m doing it with a for(0 -> w*h) but sure there is some kind of memcpy trick or something to do it faster.

  • libunicap can show a window so you can modify the camera settings, but it depends on gtk, although its lgpl, it’s another windowing system so i don’t know if that fits very well within the openframeworks philosophy. This is optional so if you don’t use it, there’s no need for gtk.


Looking forward to your solution…I was looking for a similar library but never found one. Perhaps GTK could be an option in the compilation process, switch to off by default? Although I guess it depends just how useful the GUI dialogue is, but for firewire cameras with lots of options it could be good.

great - I am looking forward to see that too - please send on something if you want me to work it into the current svn.

one thing we’d be interested in is allowing for non-requested capture sizes. so, for example, if you ask for “320x240” but the camera does another resolution, so pick the closest resolution without complaining and we will scale in the OF code. it’s not optimal (because the scaling has overhead) but it means that folks that plug in DVCAMS for example, don’t have to worry too much about getting their specific resolution to work in the code. We’ve done this now with the latest ofVideoGraber (in 0.03) for VI, since quicktime automatically scales.

about B&W, yes the best thing is to give back RGB, (and even for color, we likely witch RGB/BGR depending on the endian of the computer since OF takes every color image array as RGB). probably the easiest is to code with with pointer math. you can code it with arrays if you want and someone else can optimize it out.


About the settings dialogs, they are really good, it reads camera properties, and creates a control for every property based on the type, stepping, range… It uses three kind of controls, scales, checkboxes and combos. By now i’ve only implemented reporting of the actual values through stdout.

You can see the real thing by downloading UCview from the same page of the library, if you are in debian or ubuntu they have debs and a repository.

About selecting another resolution if the given one is not supported what i’ve implemented is something like:

Try to find a 24 bit mode, if not select the first one
On the selected format try to select the desired resolution, if it fails, select the default one (it only reports min, max and default height and width)
If BGR, activate a flag so conversion is done
If b&w reserve memory for b&w -> rgb conversion.

If you have any better idea…


  1. ofw looks great, very impressed…

i am used to opencv/sdl/ogre, and there is some damn annoying stuff that i’d use ofw for (vectors, basic 2d sprites, basic optical flow) instead.

yet, same problem as processing -

  1. no video input on linux.

thus i ultimately can’t use ofw, as all my work is video based.

i’ve seen (but never successfully gotten) toxi’s JMF workaround to function in processing in linux… (

arturos unicap sounds great - but is it in svn ? or was it decided not to include b/c of l/gpl issues?

hey cool

does the V4L code not work for you?

we **definitely **do have video capture for linux. please look in the testApp.cpp source code of the videograbber app, I think we’ve accidentally commented sections out (I was debugging something on one compiler and used python to mirror that to all compilers, including linux)…

arturo’s unicap solution is being tested now and will be in the next release…

but please try the example again - we have worked really hard to support video playing and video grabbing in linux.


Hi Arturo,

What type of V4L device did you test using libunicap?

I installed libunicap and while I was able to run the device_info program in the examples, I wasn’t able to get either of the SDL capture programs to work.
I get an “Unable to create overlay: Unsupported YUV format” which is an SDL problem I think, but in any case I wasn’t able to capture anything…

I also discovered this in the README file:

* v4l and v4l2 support is rudimentary. Tuners are currently not supported.

From a glance, libunicap doesn’t seem to support colour model conversions either, although perhaps I didn’t search deeply enough…are you implementing these?

Hi Grimus

Yes I had the same problem with the sdl example under ubuntu, I think is something with the sdl overlay mode that it uses, not with the library, in fact i think i managed to get it working. You can download ucview from the same page. It uses unicap, so if your device work with ucview, it has to work with the OF module.

About the v4l support I was looking at unicap’s code and it’s pretty much the same as v4lutils in of. The code that decides if a device can be used is actually the same in both codes, so I guess that it must support the same devices:


if( ( fd = open( devname, O_RDONLY | O_NONBLOCK ) ) == -1 ){  
if( ioctl( fd, VIDIOCGCAP, &v4lcap ) < 0 )  
if( !(v4lcap.type & VID_TYPE_CAPTURE ) ){  


deviceHandle = open(device_name, O_RDWR | O_NONBLOCK, 0);  
if (deviceHandle == -1) {  
if (xioctl(deviceHandle, VIDIOCGCAP, &capability) == -1) {  
if (!(capability.type & VID_TYPE_CAPTURE)) {  

I’ve tried it with two devices using the gspca driver.

About the color conversion, now it only supports 8bit and RGB24. Today i’ve found that although they doesn’t do color conversion automatically, it has a module with functions for that, is in the libucil directory, so i’m going to use that. I’ve seen that someone in other thread of the forum was having problems because of a device returning YUV420.

Did you code the v4lutils module? if you have any suggerences?



Hi arturo,

Yes I coded the initial v4lutils.c file.
I got my webcam working with ucview…which is great.

I had a brief look at the libucil colour conversion and it only seems to support RGB888 and YUV444. Some of the more esoteric YUV formats will need to be catered for…like YUV420. The conversion routines are also coded using floats and not integers which is slower than most other conversion routines I’ve seen so far. I’m not sure how much we care about performance, but it would be good to have fast converters.

Otherwise, so far so good!

Hi Grimus

Finally i’ve used ffmpeg color conversion routines. Using libucil was really easy (it works directly with unicap image format) but implies including a new library. Actually I didn’t realize about the types used for conversion, but looking at the code, ffmpeg works with unsigned char so I guess it will be really fast.

I’ve tried to implement every format supported by v4l, v4l2, dcam and vid21394 modules in unicap, but there are some non-planar yuv modes that are not supported by ffmpeg.