From owner-freebsd-multimedia Wed Oct 8 19:07:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA00574 for multimedia-outgoing; Wed, 8 Oct 1997 19:07:38 -0700 (PDT) (envelope-from owner-freebsd-multimedia) Received: from gaia.coppe.ufrj.br (jonny@cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA00565 for ; Wed, 8 Oct 1997 19:07:31 -0700 (PDT) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id AAA28073; Thu, 9 Oct 1997 00:07:07 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199710090207.AAA28073@gaia.coppe.ufrj.br> Subject: Re: [video] tuner input format issues In-Reply-To: <19971008201705.40619@ct.picker.com> from Randall Hopper at "Oct 8, 97 08:17:05 pm" To: rhh@ct.picker.com (Randall Hopper) Date: Thu, 9 Oct 1997 00:07:07 -0200 (EDT) Cc: jonny@coppe.ufrj.br, hasty@rah.star-gate.com, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Randall Hopper) // Joao Carlos Mendes Luis: // |Indeed, after sending them I found some other missing modifications. // |They are mostly related to X widgets interface, so I think you should // |already have seen them. // // I might have, but you might give me a clue just as a double-check. Ok. I'll send you (priately) the patches against my last sources when I get home again. // |// First, I'm assuming that selecting anything but NTSC/M, NTSC/J, or // |// PAL/M on a non-NTSC tuner isn't really a valid thing to do. Similarly // |// for selecting the three above types on, say, a Temic or Philips PAL // |// tuner. And is anything but SECAM valid on a Philips SECAM tuner? // // Yeah, I think it still would be useful. When on the tuner input, it'd be // good to grey-out the choices not supported by the tuner. These wouldn't be // greyed out when the selected input was the RCA jacks since the tuner // wouldn't be configured then (or at least "shouldn't" I'd think). When // on the tuner, this would prevent bogus attempts to configure NTSC tuners // for PAL625 formats, and vice versa. I don't know enough about PAL625 formats or Philips tuners to be sure. But I think that the trick with PAL/M and NTSC just worked because the tuner is working just as a frequency converter and an audio tuner. The Phase Alternate Line operation and the Chroma Carrier are being decoded by the bt848 chip. In theory, *if* the bandwidth for PAL625 is the same as NTSC525, *and* the audio carrier is at the same offset, it would work as a PAL tuner too. But this is improbable, or it would not be called a NTSC tuner. :) So let's stop mind melting and get back to serious work... :))))) // Also, for tuner or RCA input, it would be nice to get the 640x480x30 and // 768x576x25 hard-coded values out of the app and pull them from the driver // per input format. How would it know the input's size ? I think that's what IFORM_AUTO is for. So the right way of doing this would be to set the input to auto mode, wait for sync, and read some status register to find which mode has been chosen. I think vic does this, since it gives this warning when my camera is turned off: vic: meteor sees no signal(1)-using ntsc. Maybe Amancio is better suited to give you a help on this topic. 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