From owner-freebsd-multimedia Tue Apr 21 03:05:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA06934 for freebsd-multimedia-outgoing; Tue, 21 Apr 1998 03:05:40 -0700 (PDT) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from rah.star-gate.com (rah.star-gate.com [209.133.7.234]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA06902 for ; Tue, 21 Apr 1998 10:05:31 GMT (envelope-from hasty@rah.star-gate.com) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.8/8.8.8) with ESMTP id DAA13617 for ; Tue, 21 Apr 1998 03:05:27 -0700 (PDT) (envelope-from hasty@rah.star-gate.com) Message-Id: <199804211005.DAA13617@rah.star-gate.com> X-Mailer: exmh version 2.0.2 2/24/98 To: multimedia@FreeBSD.ORG Subject: Bt848 driver... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 Apr 1998 03:05:27 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I tweaked the driver over the weekend to fix a few more problems . One of the problem was that I was incorrectly applying an inverse gamma function to rgb capture -- translation -- the video stream was coming out too dark. This problem came up while trying to capture a yuv stream after the the application had been capturing rgb. The yuv stream was coming out "washed out". In trying to find the difference between the two capture modes , I discovered the difference. This thorny problem paves the for applications such as fxtv to capture yuv for mpeg encoding. The primary advantage for capturing yuv is that the disk thruput requirments are reduced by about 1/3 as well as the size of the video stream. Also, Roger Hardiman managed to crash the system by switching between NTSC and PAL -- he has a board which accepts NTSC or PAL and the problem so far has been isolated to boards which are capable of supporting NTSC and PAL. The temptative fix for this problem is to add a tsleep of 2 seconds in video_open to give the Bt848 enough time to fully initialize . There is perhaps a much quicker solution and I am waiting from Roger if he has managed to solve the problem. The current driver does not address any of the problems that some users are experiencing with the driver not recognizing their tuner. It seems that Bt848 board manufacturers are finding new and novel tuner parts . An easy way to determine if the card is operating well is to feed it a TV signal via one of its video input ports and not to the tuner port since the latter is most cases that a user is having problems is probably not programmed properly. Also you can test the Bt848 with the following command: fxtv -colorbars If color bar is displayed, it means that the Bt848 circuitry is working. Last but not least the problem that some PAL users are having with fxtv core dumping is still unresolved;however, I most say that I have not heard a single NTSC user having the same problem which kind makes me think that is a buffer or shared memory resource limitation . The updated Bt848 driver is at: ftp://rah.star-gate.com/pub/bt848.tar.gz Cheers, Amancio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message