From owner-freebsd-multimedia  Sat Oct  4 20:42:48 1997
Return-Path: <owner-freebsd-multimedia>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id UAA22486
          for multimedia-outgoing; Sat, 4 Oct 1997 20:42:48 -0700 (PDT)
Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA22478
          for <multimedia@FreeBSD.ORG>; Sat, 4 Oct 1997 20:42:40 -0700 (PDT)
Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1])
	by rah.star-gate.com (8.8.7/8.8.5) with ESMTP id UAA00403;
	Sat, 4 Oct 1997 20:42:31 -0700 (PDT)
Message-Id: <199710050342.UAA00403@rah.star-gate.com>
To: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br>
cc: multimedia@FreeBSD.ORG
Subject: Re: bktr -> NTSC - PAL/M 
In-reply-to: Your message of "Sat, 04 Oct 1997 20:03:39 -0300."
             <199710042303.UAA06680@gaia.coppe.ufrj.br> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sat, 04 Oct 1997 20:42:31 -0700
From: Amancio Hasty <hasty@rah.star-gate.com>
Sender: owner-freebsd-multimedia@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

Just let us know precisely what you have in mind and we will take from 
there.
	Cheers,
	Amancio

>From The Desk Of Joao Carlos Mendes Luis :
> Hi,
> 
>   I finally managed to make my WinCast/TV tune PAL/M in FreeBSD.  But it
> has been done in kernel defaults, disallowing the use of a composite video
> NTSC camera for videoconferencing aplications.
> 
>   Also, the composite video input could also be used with other formats,
> independently of the tuner.  I think that the best approach is to add
> an ioctl to change video input format.  Changing between NTSC and PAL/M
> is not a problem, I'll try to get a prototyype this weekend.  But 
> changing between NTSC (525 lines) and traditional PAL formats (625 lines)
> could be a problem.
> 
>   I could limit the driver to accept format changes only between same
> resolution ones.  Is this an acceptable restriction ?
> 
>   It's easy to see from the sources that this driver was adapted from
> the existing meteor driver.  I know nothing about the meteor card,
> but I think that these similarities are restricting the features
> of the BrookTree (wonderful) chip.  Should we limit frame grabber
> features to the commom ones, or should we use every possible feature
> available and let the user level software select which ones to use ?
> 
> 					Jonny
> 
> --
> Joao Carlos Mendes Luis			jonny@gta.ufrj.br
> +55 21 290-4698				jonny@coppe.ufrj.br
> Universidade Federal do Rio de Janeiro	UFRJ/COPPE/CISI
> PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2  83 5F E3 26 BF 0F EA 67