Hi Bryan! Jeroen Vreeken wrote: > > Serguei Miridonov wrote: > > > > "Bryan K." wrote: > > > > > > It's been awhile. Anyhow, I'm looking to do some serious video work with a > > > linux box. This is what I need: > > > > > > * 4 - 8 video inputs > > > * Ability to record each input at 640x480 (or higher) individually in 24 - > > > 48 hour intervals I have such a solution for home video observation with 384x288 PAL (more makes also no sense as I use cheap video cams which already have no better resolution). I use some fast analog semiconductor switches (less power consumption than normal reed relais) more or less connected to the printer port to control them. Disadvantage: the frontend needs some frames to get in sync after each switching as the cam outputs are not sync'ed to each other (this is quite impossible with cheap ccd cams, maybe better ones may have some sync. mechanism (?) - theoretically possible - I am very interested in any guy who realized such a solution!!!) But this was good for my purposes as I only doing uncompressed grab with around 1 fps with some postprocessing (It does some movement detection and throws pictures with no movement away and keeps only the sequences with some tracking list). > > > > If you need to record from 4-8 inputs continuously, you will need 4-8 > > separate TV capture cards, I believe. However, if you wish just to take > > snapshots (say, 1-2 per second from all inputs), may be you can do it with > > DC10plus card which can be programmed to take signals from 4 composite inputs > > right of the box (however, you will need to add this functionality to the > > driver, and make S-Video cable for 2 composite inputs instead of Y/C). > This solution also needs (nearly) no soldering ;-) > I don't think you would need to change the driver, if it has the > VIDIOSCHAN ioctl implemented you should be able to use this for > switching between the inputs. I can't agree with that. The driver maps already the 'virtual' inputs of the VIDIOSCHAN to physical ones of the video frontend in hardware in a useful manner. Here an example: if you use the Buz or DC10 or DC1 you have a Philips frontend with some video inputs (e.g. the SAA7110 has 6, the SAA7111 has 4) - which can be used as single compsite input each or two of them can be combined as S-Video input (Y/C). The bt848 has also the possibility to switch between 3 composite or 2 comp. and one S-Video input - which depends also on the manufacturer of the hardware. And the drivers only map the inputs which makes sense, so that one which are 'normally' used with not modified cables. Of course, the i2c driver of the frontend of a saa7110 doesn't, but the driver dedicated for the hardware _should_ do it. Otherwise the user will get for cards with such a SAA7110 chip 9 input selections and can guess which one is the right for his connection.... (this was hard enough during reengineering the hardware ;-) ) This is not normal driver usage.... > > > > > > So, can someone tell me what I should be looking for, what is the > > > likleyhood of getting this to work etc? Also, does anyone have a source of > > > good video capture boards, fairly standard, maybe some with 2-4 inputs? > > > > Almost all have both composite and S-Video inputs. Some cards can be > > programmed so that S-Video input becomes two composite. Some cards, like > > DC10plus, have internal composite connector besides those ones on rear metal > > plate. So, in particular DC10plus can be used as 4-inputs card. If you have > > good soldering skills, may be you can get all available 6 composite inputs > > from it ;-). > > > > Virtualy unlimeted inputs could achieved by using frequency > multiplexing, > in other words play for cable company and modulate each video source on > a single cable (simple video modulators and some technical knowledge > will do) and use VIDIOCSFREQ for switching. This is quite expensive, as you need modulators on each cam and you also need a capturing card with tuner. Then you need higher quality cables. Using plain video signals for less quality - as im my solution - needs just cheap unshielded three- wire twisted pair (supply/video/ground) cables as the bandwith is not that high and adjustable terminators can minimize reflections. And by the way: the quality is at least that high as it gets crunshed by a cheap modulator.... After all one disadvantage is much more drastic than my solution: You can't get synchronous inputs - so after switching you need time for the tuner to lock on the new carrier, when the carrier is stable you get some completely unsynchronous video signal and the video frontend needs again time to synchronize on that video signal (after it gots completely weird during tuner recalibration). This costs not only some frames - I wouldn't bet that half a second is enough for it. Bye, Wolfgang -- Linux _is_ user-friendly. It's just not ignorant-friendly and idiot-friendly.
