From owner-freebsd-multimedia Tue Jan 1 13: 4:54 2002 Delivered-To: freebsd-multimedia@freebsd.org Received: from mcqueen.wolfsburg.de (pns.wobline.de [212.68.68.5]) by hub.freebsd.org (Postfix) with ESMTP id 6386F37B421 for ; Tue, 1 Jan 2002 13:04:45 -0800 (PST) Received: from colt.ncptiddische.net (ppp-335.wobline.de [212.68.71.56]) by mcqueen.wolfsburg.de (8.11.3/8.11.3/tw-20010821) with ESMTP id g01L4N807101; Tue, 1 Jan 2002 22:04:23 +0100 Received: from tisys.org (jodie.ncptiddische.net [192.168.0.2]) by colt.ncptiddische.net (8.11.6/8.11.6) with ESMTP id g01L4iX03224; Tue, 1 Jan 2002 22:04:45 +0100 (CET) (envelope-from nils@tisys.org) Received: (from nils@localhost) by tisys.org (8.11.6/8.11.6) id g01L4RZ02668; Tue, 1 Jan 2002 22:04:27 +0100 (CET) (envelope-from nils) Date: Tue, 1 Jan 2002 22:04:27 +0100 From: Nils Holland To: Randall Hopper Cc: Roger Hardiman , freebsd-multimedia@FreeBSD.ORG Subject: Re: bktr / fxtv problem revisited... Message-ID: <20020101220427.A2629@tisys.org> References: <20020101134607.A151@tisys.org> <20011230170550.A33828@tisys.org> <20020101104922.C19839@nc.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020101104922.C19839@nc.rr.com>; from aa8vb@nc.rr.com on Tue, Jan 01, 2002 at 10:49:22AM -0500 X-Operating-System: FreeBSD jodie.ncptiddische.net 4.5-PRERELEASE FreeBSD 4.5-PRERELEASE X-Machine-Uptime: 9:52PM up 8:22, 1 user, load averages: 0.26, 0.17, 0.12 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Jan 01, 2002 at 10:49:22AM -0500, Randall Hopper stood up and spoke: > > I don't know enough about PAL to explain why you'd want PAL/N or PAL/BDGH > (maybe Roger can offer some advice? he's our resident bktr expert), but I > the results you see are indicative of "capture problems". In the bktr > chip, there's a little DMA RISC program running, churning out pixels and > blasting them onto the memory bus. When "something happens" > (e.g. insufficient bus bandwidth, bad input signal, etc.) that prevents it > from keeping up at full speed, it can stop and wait for the beginning of > the next scan line. One of the microcode instructions tells the chip where > to resume executing the program when that happens. If you look at your > second picture, that may help to explain why most of the blank spans are on > the right of the screen. Similar processing can happen with entire fields. > That is if "something happens" where the chip fails to deliver sufficient > number of lines to constitute a field, it can pause, skip to the end of the > field, and resume. This helps explain many blank lines in windows (in > large windows, they'll be alternating lines since you are displaying both > fields, not just one). I'm no expert on this, but I guess that *might* have to do with my VIA KT-133A / 686B chipset combo. If you are informed about the issue, then you may know that this chipset (especially the 686B Southbridge) has a bug in that it tends to produce data loss when copying large files from a drive on IDE channel one to a dive on IDE channel two. A discussion about that just went on at freebsd-hackers. Now, anyway, this big appears mostly when there's heavy load on the PCI bus, which the WinTV card can surely produce. Many mainboard manufacturer's (including mine) have placed a workaround in their BIOS, which basically (I'm not expert if I use the wrong terms) does not grant a DMA Busmater three "bursts" before the CPU accesses the bus again, but instead makes the CPU access the bus after each individual burst. I guess that this may actually have some undesirably side effects on the WinTV card which is trying to move its data into my graphic card's memory, since it gets interrupted three times as often as is common on "unflawed" mainboards. Now, if this assumption is true, there may actually be no fix for the issue I have been seeing with my WinTV card available. I guess I might want (only for a short test run) flash a BIOS that does not (yet) contain the above mentioned bug fix and thus grants the PCI bus to any bus master for a longer period of time. I will then re-flach my current BIOS to prevent the (much more dangerous) possibility of data corruption on my HD, but at least this little experiment would allow me to find out if my assumption of the cause of this problem is true. > You only see all this trash because you're using DGA which is dumping it > directly on your screen. If you disable it (fxtv -disableDirectV), when > your tuner is misconfigured for your video stream, the driver will rarely > get a successful frame, and fxtv will only display those the driver says > were successfully captured. That doesn't mean what frames get through will > be flawless, but only that the more mutilated ones won't make it through. If I turn of DGA, I get about one frame all 2 seconds, even in a small window. I wonder if I should normally get slightly more than that, even with DGA disabled... Greetings Nils -- Nils Holland Ti Systems - FreeBSD in Tiddische, Germany http://www.tisys.org * nils@tisys.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message