I don't want a TV/Tuner card.. thingy, because I want video only. No sound, no frills. Just video. Fewer things can go wrong this way ;) Also, frame grabbers typically support bus-mastering, which is good for real-time capturing, i.e. more predictable and more reliable. I might be wrong, but that's my requirements. -- Georgios Kapetanakis Department of Computer Science University of York ----- Original Message ----- From: "Martin Peach" <martinrp@xxxxxxxxxxxxxxxxx> To: <video4linux-list@xxxxxxxxxx> Sent: Monday, October 21, 2002 3:52 PM Subject: Re: Frame grabbers with bt8x8 chipset > Georgios Kapetanakis wrote: > > > > Hi all, > > > > I know this is getting slightly away from the core interest of the list, but > > I need your help once more. I am convinced now that getting a frame grabber > > with a bt8x8 chipset is the best way to go, as far as driver support is > > concerned (bttv). > > > > I know of only two frame grabbers with this chipset: > > - Imagenation PXC200AL > > - Sensoray 611 > > > > Are there any more? Please note that I am interested in frame grabbers for > > computer vision, not TV/Tuner cards.... > > But what's the difference between a computer vision grabber and a TV > card with the channel set to the raw video input? > Following for example is the output of a test program I wrote using the > functions in linux/videodev.h to query the bttv driver. You can set the > channel to 1 to receive video. I'm pretty sure that the video quality is > mostly limited by the video format itself, and that any grabber will > produce similar output for a given NTSC or PAL signal. The only other > issue is progressive scan, where you grab only a part of an image, but > there you might be better off getting a dedicated camera with image > processing built into it. > > > > Hello world. Today we are going to look at the video grabber at > /dev/video > name of /dev/video: BT878(Hauppauge (bt878)) > VID_TYPE_CAPTURE Can capture to memory > VID_TYPE_TUNER Has a tuner of some form > VID_TYPE_OVERLAY Can overlay its image onto the frame buffer > VID_TYPE_CLIPPING Overlay clipping is supported > VID_TYPE_FRAMERAM Overlay overwrites frame buffer memory > VID_TYPE_SCALES The hardware supports image scaling > Type 0xEB > 4 channels > 1 audio device > Max width: 768 Max height: 480 > Min width: 48 Min height: 32 > Video frame buffer base 0xe8000000 > height 768 width 1024 > depth 16 > bytes per line 2048 > > * * * Channel 0: Television > has 1 tuner > Flags: 0x3: has tuner; has audio > Type: 0x1: TV; not camera > Norm: 0x1: NTSC > brightness 0x7FFF > hue 0x7FFF > colour 0x7D70 > contrast 0x6B84 > whiteness 0x0 > depth 0x10 > VIDEO_PALETTE_RGB565 565 16 bit RGB > * * * Channel 1: Composite1 > has 0 tuners > Flags: 0x2: no tuner; has audio > Type: 0x2: not TV; camera > Norm: 0x1: NTSC > brightness 0x7FFF > hue 0x7FFF > colour 0x7D70 > contrast 0x6B84 > whiteness 0x0 > depth 0x10 > VIDEO_PALETTE_RGB565 565 16 bit RGB > * * * Channel 2: S-Video > has 0 tuners > Flags: 0x2: no tuner; has audio > Type: 0x2: not TV; camera > Norm: 0x1: NTSC > brightness 0x7FFF > hue 0x7FFF > colour 0x7D70 > contrast 0x6B84 > whiteness 0x0 > depth 0x10 > VIDEO_PALETTE_RGB565 565 16 bit RGB > * * * Channel 3: Composite3 > has 0 tuners > Flags: 0x2: no tuner; has audio > Type: 0x2: not TV; camera > Norm: 0x1: NTSC > brightness 0x7FFF > hue 0x7FFF > colour 0x7D70 > contrast 0x6B84 > whiteness 0x0 > depth 0x10 > VIDEO_PALETTE_RGB565 565 16 bit RGB > > > > /\/\/\/*=Martin > > > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
