Date: Fri, 17 May 2002 11:23:17 -0400 From: Carlos Ugarte <cau@cs.arizona.edu> To: Marco Molteni <molter@tin.it> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: writing a driver for the IBM ultraport camera (USB) Message-ID: <15589.8293.771100.995862@pc-ugarte.research.att.com> In-Reply-To: <20020517072741.9472.qmail@cobweb.example.org> References: <20020516091509.1671.qmail@cobweb.example.org> <15588.12506.65605.999864@pc-ugarte.research.att.com> <20020517072741.9472.qmail@cobweb.example.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Marco Molteni writes: > thanks for the detailed answer, and thanks for taking the time of > writing a real answer instead of quickly jotted words :-) Glad I could help! > Regarding the Philips webcam you are working on, I am wondering how you > will handle the decompression part, which as you know is done in Linux > by a binary only driver for NDA reasons. Fortunately, decompression on the Philips cameras is not necessary for all resolution and frame rate combinations. Without compression, it is possible to do 30 fps on SQCIF (128x96) and QSIF (160x120), 25 fps on QCIF (176x144), and 5 fps on SIF (320x240) and CIF (352x288) (for some cameras). The only resolution that can't be used is VGA (640x480). My intent is to make it work for these cases, and then see if I can enter into an NDA with Philips and get the details necessary to implement compression. If they agree, I imagine I would be able to distribute a binary that only handles compression. For those wondering, USB 1.x provides a bandwidth of 12 Mbps. For these Philips webcams, I have read that using compressed video at the highest settings it is possible to support two webcams on the same bus. Three cameras would exceed the availability of bandwidth on the bus. > I have a question on the USB architecture. From my limited understanding > the various USB devices are divided in "classes", for example storage, > or human interface like a mouse. Each class of device is supposed to > have a specific API in addition to the generic USB one. On the USB web > site I was able to find the class document for still video cameras, but > it seems there is nothing regarding, what's the english for it, > continuous video cameras. Are you aware of any standard for these devices? That sounds about right. There are standards for certain types of devices (hubs, keyboards, mice, audio input, audio output, mass storage, volume knobs, printers, scanners, ...). Manufacturers are encouraged to conform to the standard. Sometimes they opt not to, sometimes they get it wrong. In some cases there is no standard for them to use so they come up with their own. I believe this is the case for these webcams; this is why there is a multitude of drivers for them. > Exactly! I know nothing about video, but I understand it would be crazy > (or masochistic) to provide a different API per video driver. I am aware > too of video4linux, which good or bad is at least a standard. Looking > for a standard I found SANE (http://www.mostang.com/sane/) which is or > tries to be the Unix (better?) equivalent of TWAIN. Although SANE means > Scanner Access Now Easy, it talks also about video cameras. > > Any ideas on this? Hmm... I had heard of SANE before but thought it was limited to scanners. A quick look through their web site indicates that they are working on supporting digital (still) cameras. From what I can tell the applications are all geared towards working with still images that can be captured from some device through SANE. While these webcams could be made to work like that, I think the eventual goal is to support some streaming sort of video more along the lines of a TV card. My thoughts had been to find an existing interface to conform to. As Daniel suggested, I (eventually) intend to look at the bktr driver and see how good a fit that is. I expect there is something there we could leverage, but there would also be the need to add new API calls. The other alternative I had been considering was to provide V4L support. The payoff is that there are a number of applications written to this standard. It's a lot more work, though (not only would the driver have to conform to V4L; V4L support would have to be added in the first place) and it's not clear that V4L is the best target (given the work on V4L2). It's here today, but it may not be here tomorrow. Carlos -- Carlos A. Ugarte cau@cs.arizona.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15589.8293.771100.995862>