Date: Tue, 1 Jan 2002 10:49:22 -0500 From: Randall Hopper <aa8vb@nc.rr.com> To: Nils Holland <nils@tisys.org> Cc: Roger Hardiman <roger@cs.strath.ac.uk>, freebsd-multimedia@FreeBSD.ORG Subject: Re: bktr / fxtv problem revisited... Message-ID: <20020101104922.C19839@nc.rr.com> In-Reply-To: <20011230170550.A33828@tisys.org>; from nils@tisys.org on Sun, Dec 30, 2001 at 05:05:50PM %2B0100 References: <20020101134607.A151@tisys.org> <20011230170550.A33828@tisys.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Nils Holland: |http://www.tisys.org/misc/fxtv_small.png |http://www.tisys.org/misc/fxtv_big.png | |1) I have now found out that when I start my X server with 16bpp instead |of 24bpp, I can switch fxtv to full screen more or less successful. The |only problem that sometimes remains is that the picture may look |"interlaced", that is, only every even scan line seems to be drawn, while |every odd scan line remains black. ... Now, is fxtv / bktr actually |limited to 16bpp, or is this just something I am seeing? It's not limited to 16bpp. Folks have used it in 8/16/24/32 bpp. |2) When I select the PAL/BDGHI mode, the picture seems a little "jerky", |meaning that it hangs and then moves again. If I select PAL/N instead, the |picture moves smoothly. I wonder what the TV norm actually has to do with |this behavior, however. Since I live in Germany, I know that I will have to |use some kind of PAL, but I'm unsure about the differences of PAL/BDGHI and |PAL/N. ... |Well, I have hooked up my satellite receiver via an antenna cable |... PAL/BG signal ... As a workaround, I set fxtv to "PAL/N" mode, and |interestingly, all the above described problems go away. TV looks good |both in small window and full screen format. ... |Then, I really wonder in what way the selection of PAL/BDGHI vs. PAL/N |could influence how "smooth" my picture moves. 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). 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. Randall -- Randall Hopper aa8vb@nc.rr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020101104922.C19839>