From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx3.redhat.com (mx3.redhat.com [172.16.48.32]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3UDst0q003057 for ; Wed, 30 Apr 2008 09:54:55 -0400 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx3.redhat.com (8.13.8/8.13.8) with SMTP id m3UDsfkE009517 for ; Wed, 30 Apr 2008 09:54:42 -0400 Date: Wed, 30 Apr 2008 15:54:15 +0200 From: Daniel =?iso-8859-1?Q?Gl=F6ckner?= To: Farkas Levente Message-ID: <20080430135414.GA1198@daniel.bse> References: <48185C99.807@bppiac.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48185C99.807@bppiac.hu> Cc: video4linux-list@redhat.com Subject: Re: [Fwd: [gst-devel] RFC: multi channel frame grabber card support] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: video4linux-list-bounces@redhat.com Errors-To: video4linux-list-bounces@redhat.com List-ID: On Wed, Apr 30, 2008 at 01:48:41PM +0200, Farkas Levente wrote: > we'd like to build in this case n pipeline for the n input channel. one > of the simple example IVC-100 card which has one bt878 chip and 4 > composite input and one 4 channel multiplexer. Are you familiar with the capabilities of the bt878? If not, here is the datasheet: http://conexant.com/servlets/DownloadServlet/DSH-200115-001.pdf?docid=116&revid=1 You can only capture from one channel at a time. So you will get only 6.25 full size PAL frames per second on each channel if you use all four channels AND THE CHANNELS ARE SYNCHRONIZED. This synchronization can only be done with some cameras. If you can't synchronize your framerate will drop even more. I don't know if there are additional resynchronization delays if the bt878 doesn't detect vertical sync when it is expected. The card's driver would have to change all parameters on IRQ. Can we guarantee that the interrupt is handled in Linux before the next frame starts? The "white crush" adaptive algorithm of the chip will result in bad pictures if the inputs have completely different white levels. It should be disabled. If this is to be done, I propose that struct v4l2_buffer should be extended to point to the parameters that should be used for the picture. How these parameters should be stored is another question.. Daniel -- video4linux-list mailing list Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe https://www.redhat.com/mailman/listinfo/video4linux-list