[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-video
Subject:    Re: [video4linux] Video capture card advice
From:       Aaron Colwell <colwaar () charlie ! cns ! iit ! edu>
Date:       1998-08-06 16:01:24
[Download RAW message or body]

I wanted to combine 2 emails I got from people concerning Buz capturing 
and device driver development for the Buz. I figure that this could help
bring together the people who seem to be interested in developing a driver
for this card.

On Thu, 6 Aug 1998, Daniel Dunbar wrote:

> no, you are thinking about single frame decompression.... check page 21
of the zr36057 > pdf if you have it.... notice the section headers for
compression and decompression.  > I looked at these pages. Does this mean
that I have to compress the frame into a fragmented buffer and then
decompress it into that buffer to get the uncompressed frame? That is a
rather interesting way to do things. I am particularly interested in
getting uncompressed frames for 2 reasons.  First it is how the bttv
driver does capturing and it seems to be the preferred method of capturing
for the new proposed API. I realize that later we want to support
compressed capturing to buffers, but I'd like to get the uncompressed
stuff down first. Secondly uncompressed frames are easier to pass to
encoders that will software compress the frames. Not everyone needs or
wants to capture to motion jpeg. Ideally it would be nice for someone not
to be limited to a particular codec for capturing just because that is
what the card supports. 


Dave Perks <dperks@ibm.net> wrote:  
>I'm working on a Buz driver.  
>So far my driver (originally based on bttv.c) can watch TV.  I have
>captured a couple of JPEG compressed frames into the mmap buffer.  There
>is still a lot to be done before the driver is ready for even alpha
>release.  At least being able to use it without a reboot afterwards would
>be nice :-(

> I basically stuck to the BTTV interface as of kernel 2.1.109 -- the 
> format field of the capture currently specifies the desired compressed
> size of the frame but in future a new ioctl should be added, and the
> sync call returns the actual length of the data if successful since it
> will vary. 

>I'd hoped to release the driver last weekend but things are proceeding
>slower than planned and I'm not working on it 7x24 either...  Any
>suggestions of a suitable ftp site will be appreciated, I don't have one
>myself.

This is just an advertisement for this guys driver and I included it to
recognize someone else who is writing a driver for the Buz. I might be
able to provide space for the driver on my webpage, but I cant grant you 
ftp access to the machine. Perhaps we could work out some way of uploading
to my machine and then I can put it on the web. I know it is a round about
way of doing things, but it is all I can offer right now.

Daniel Dunbar wrote:
>if you are interested in helping/leading the buz driver project i would
>be most grateful.

I would be happy to help/lead development of a buz driver project. First I
have to go out and buy the card of course, but after that small task I
plan to start writing driver code for it. I want to write the driver for
the new proposed API though. I think it has a lot of features that will
prove useful to a larger set of people and hopefully will encourage more
serious video applications to be developed for Linux. I have not heard
whether anyone has created a modified version of videodev.h and videodev.c
for the new API proposal. Perhaps this is something else I'll have to do
before I can start on the Buz driver. Once again comments are always
welcome and appreciated.

Aaron

------------
To unsubscribe from this list send mail to majordomo@phunk.org with the
line "unsubscribe video4linux" without the quotes in the body of the
message.

[prev in list] [next in list] [prev in thread] [next in thread]