Hi Miles, > seems we are working on the EXACT same thing. I had noted the EXACT problem > you have, and am working on a solution. That's a good thing, we can probably learn some interisting things from each other ! > If you are interested, I have the maximum frame rates achievable without > syncing the cameras.... > > 1 camera / 25 total > 2 cameras/ 16.67 total > 3 cameras/ 10 total > 4 cameras/ 7.07 total > > These are rough numbers with a simple model of the video signal, and the > actual sync requirements of the card ignored. However, I have tried it with > the associated number of cameras, and noted that if I go above 16,10,7 I > get the chopped frames, so I'm pretty close ;-) Hmm, interesting! can you give me some more info on how you calculated those numbers and the model you used ? > I would be interested in seeing the work you have done on opening four > video streams to capture to. I am working with vcr by Bram, and will be > changing to 4 AVIs today. I have very limited processor to work on (C3 > 800), so it will be interesting. I wrote something from scratch using the v4l2 API and the RTE mpeg coder library (form zapping/mp1e) . At the moment it consists of a few cooperating processes, all doing a specific job. They communicate throught pipes and fifos for now, but when performance gets a hot issue I can rewrite that to sheared memory quite simple. The RTE library is not fully reentrant at this moment, thus the seperate processes with pipes. The rte author, Michael Schimek, told me this is likely to change at some time in the feature, so when it gets reentrant the grabber and coder processes will probably become threaded instead of seperate processes. The current, working, prototype setup : - grabber process : Does the /dev/video handling and frame capturing. The captured frames are split up into 1-6 seperate streams of YUYV frames. Those are written to pipes that go to the coders. - 1-6 coder process : using the RTE mpeg coder library. Those read the YUYV streams and convert them to mpeg streams, fed into 1-6 fifo's. - the main controlling process. This starts the grabber and coder processes, and reads the mpeg streams from the fifo's into 6 ringbuffers. When a external trigger comes in (buttons, door contacts, etc), one ore more ringbuffers are written to disk. With the current setup (using synced cams), we can capture 6 streams at 720x568, mpeg code them, and write to disk, using a PIII/466, with 25fps total, no frame drops. The prototype switch is homebrew and low-cost, just 2 4066 analog switcher IC's, driven from the printer port. A small addition to the bttv driver switches the cams at the interrupt routine during the VSYNC, and is performing very well. > With regards to the VSYNC, I am investigating video buffers (some aren't > that expensive..), and will let you know how I go. That is what we started to investigate last friday. I am very interested in the possible solutions, since my customer thinks synced cameras are old fashioned, and thus he probably will not agree with it... The hardware we found so far for doing this seems to be just as expensive as a BT787 chip :( Please keep me informed ! > Stay in touch! Sure will ! I exchanged some ideas with Fabio Roger <fabroger@xxxxxxxxxxxx> too, he's working at almost the same setup. It seems that we're not alone :) /Ico PS. If more people are interested in this project, or working on similar things, might it be worth creating a seperate project for it, with a little mailing list and file archive ?
