Hi,

I found this:

http://pastebin.com/T4jkeE6F

in a zip file called vfp.tar.bz4 somewhere on the web, it seems not maintained since ages but obviously it must have compiled at some time in the past. I am tying to see whether I can hack a quick and dirty program that is able to open an v4l device and do some simple things and maybe grab a frame (if I can somehow manage to keep the motivation level above the frustration level for a long enough time).

_IOR is defined as

#define _IOR(x,y,t) (IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)

and in FPC I have found a *function* in kernelioctl.pp with the same name that seems to serve the same purpose, except that it is a function and not a macro.

And here comes the problem:

#define VIDIOCGCAP _IOR('v',1,struct video_capability) /* Get capabilities */

obviously the following will not compile since the function cannot run
at compile time:
const
    VIDIOCGCAP          =   _IOR(Ord('v'), 1, SizeOf(video_capability));

in the above mentioned ten years old pascal file there is the following:

//define[_IOR(][,#1,#2)][_IOC(2,ord('#0'),#1,sizeof(#2));]
const
    VIDIOCGCAP     = _IOR(v,1,video_capability);

The first line looks like it is meant to be understood by some kind of prepocessor but FPC does not seem to understand this. The zip file also contains a folder with something that looks like it is a macro processor that is meant to be used to process this file and a makefile to start the entire thing but there are compile errors and and the perceived hack-level of this entire thing is quite high.

What would be the most reasonable thing for me to have the handful of constants defined that I need (I don't need the entire API, only the most basic things to open my webcam and grab a frame¹). Should I use variables and initialize them at runtime? Or should I define functions instead of constants?

How should I now proceed? Should I try to make this entire thing (including its macro pocessor) compile with a current FPC? I don't really like this idea because v4l1 is deprecated anyways. And the separate macro processor and the makefile also somehow does not look tlike the right approach to me, there must be a better way. And I don't need the entire full blown thing, only a small subset for a small quick and dirty program to try a little idea of mine (might prove to be throw-away code anyways).

_____
¹) my current solution is just piping RGB data from streamer through a named pipe to my application, I just wanted to know if i could get rid of this external process and communicate directly with the camera and also be able to control gain and exposure directly and in real time, therefore I am investigating v4l/v4l2. I haven't found any other v4l implementation for FPC.

In our previous episode, Bernd said:

I always used a small program to simply calculate the hex constants.

Hi!

I did convert the V4L2 headers some time ago, but did not publish them yet. If you want to, I can send you the Pascal file. I tested it with a radio tuner, so it should work mostly.

Regards,
Sven

2011/4/24 Sven Barth :

This would surely be helpful. Please consider also releasing them with an FPC compatible license, because while searching on google I have seen quite a few discussions where users were desperately searching for any way to access the v4l API but no existing and working solution for FPC seems to exist at the moment and porting all these overly convoluted and obfuscated kernel headers into something readable and usable is really not a trivial

@FPC devs: Is it ok to put the usual FPC header on top of the file instead of it's original header? I'm too less experienced in those license/copyright related things to decide this...

This is the header of the original .h file:

===header begin===

/*
* Video for Linux Two header file
*
* Copyright (C) 1999-2007 the contributors
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* Alternatively you can redistribute this file under the terms of the
* BSD license as stated below:
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. The names of its contributors may not be used to endorse or promote
* products derived from this software without specific prior written
* permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. *
* Header file for v4l or V4L2 drivers and applications
* with public API.
* All kernel-specific stuff were moved to media/v4l2-dev.h, so
* no #if __KERNEL tests are allowed here
*
* See http://linuxtv.org for more info
*
* Author: Bill Dirks
* Justin Schoeman
* Hans Verkuil
* et al.
*/

===header end===

Regards,
Sven

Well, you can have it with Lazarus in:

http://wiki.lazarus.freepascal.org/5dpo

the TSdpoVideo4L2 component has the V4L2 translated...

Paulo Costa

2011/4/24 Paulo Costa :

the TSdpoVideo4L2 component has the V4L2 translated...

Thanks. This is interesting. I saw this before but didn't look deeper into it after I read "UVC compliant USB cameras" in the wiki, this seemed to imply for me that it would only work with the subset of cameras that are supported by the uvcvideo driver.

If this is really a full featured v4l2 implementation which speaks the v4l2 protocol (and not the UVC protocol(?) or some proprietary communication with the uvc driver) then maybe the wiki page should explicitly mention this or at least clarify what "UVC compliant camera" means and how this differs from v4l2.

2011/4/24 Paulo Costa :

Probably you are right. Let me know how does it works for you. Historically, we had a V4L unit for Kylix that was used with a Bt878 Frame Grabber and we had to build the new component when we wanted to use the USB cameras. Back then, some drivers were not available as V4L2.

I had some more time to look into this now, read some more documentation and looked into the 5dpo sources.

Actually it really seems to be a full featured v4l2 implementation, unfortunately I have only one v4l2 device to test it and the driver of this device itself seems broken/incomplete. This diver will accept a lot of different format settings without complaining but send its data always as the same (probably jpeg) that I was not yet able to decode. Other Applications have problems with this diver too.

The problem with v4l as I see it now is that it does not really define a nice standard that could be easily used by the application. Only the handshaking and camera settings are standardized, the actual data is allowed to be transmitted in any of a myriad of possible formats, the kernel guys don't like (don't allow) format conversion in kernel space, so the driver just pumps the raw data from the camera to the application. The application itself must be able to handle a zillion of different video formats and encodings. Therefore it seems (from what I understand so far) there exists a set of libraries that can (or should) be used to wrap the raw v4l device into something that is more application friendly and attempts to solve this problem.

This is what I will investigate next.

Currently I have an old v4l1 device with no existing v4l2 driver, so I needed some way to access a v4l1 device. The units from 5dpo do not contain the needed definitions to use v4l1, only v4l2.

So I wrote a bare bones minimal v4l1 unit from scratch, manually translating the headers from the FreeBSD (better documentation) videodev.h file, that contains only the absolute minimum that is needed to open a v4l1 camera, set the image settings (brightness, etc) and grab frames. Fortunately my camera outputs uncompressed RGB24 data.

I am attaching the unit for documentation purposes (its really legacy stuff, no new devices use v4l1 nowadays but there are still some old cameras around needed for special purposes), maybe somebody else will stumble over this while searching for the same problem. It also contains a class with some methods that demonstrates how to open the cam and grab images, I have used it in this current form to sucessfully grab streaming images from an old QuickCam Express that uses the qc-usb driver on kernel 2.6.24.

Bernd

2011/4/24 Paulo Costa :

Probably you are right. Let me know how does it works for you.

I have further studied the entire v4l thing and there is something that could be improved in the SdpoVideo4L2 component: There exists a library libv4l2 that is an official part of the Linux V4l2 project. It implements the format conversions that were part of each individual V4L1 driver but are not allowed to be done in kernel-space anymore with V4L2 and have all been moved into one user space library and should be used by all applications using the V4L API.

This library exports functions that wrap open/close/ioctl/mmap/munmap and work like their native counterparts except that they intercept certain ioctls and make the cameras all magically support not only their native pixel formats but also at least BGR24 and YUV420p as a common denominator. The decompression and/or format conversion will happen transparently on the fly, it will be as if the driver itself natively supports this format.
http://hansdegoede.livejournal.com/3636.html

This means the only change that is needed to SdpoVideo4L2 would be to replace all calls to FpOpen(), FpIoctl(), FpMmap() etc... with calls to v4l2_open(), v4l2_ioctl(), v4l2_mmap() etc. and all existing (known) V4L2 cameras could then be set to BGR24 and would deliver uncompressed 24bit BGR video.

If I have some time next weekend I will make a patch against SdpoVideo4L2 (with an ifdef) that allows enabling this functionality.

Bernd