Date: Mon, 29 Sep 1997 21:36:02 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Amancio Hasty <hasty@rah.star-gate.com> Cc: User Al Johnson <Al.Johnson@AJC.State.Net>, freebsd-multimedia@FreeBSD.ORG Subject: Re: fxtv Message-ID: <19970929213602.53357@ct.picker.com> In-Reply-To: <199709300048.RAA06881@rah.star-gate.com>; from Amancio Hasty on Mon, Sep 29, 1997 at 05:48:54PM -0700 References: <19970929191238.29355@ct.picker.com> <199709300048.RAA06881@rah.star-gate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Amancio Hasty: |>Randall Hopper: | |> Also, you'll see that when your video window is situated so X % 3 == 0, |> the window looks OK, whereas with X % 3 == 1, your video will be |> displayed with RGB mapped to BRG, and with X % 3 == 2, RGB -> GBR. All |> that is changing from the app side is the start address in PCI memory, |> but it somehow seems | |Interesting, are you trying to capture odd widths ? No, Fxtv does ensure even widths. Reproduced these probs with the default 324x244 window that Fxtv 0.44 comes up with. Experimenting some more, the RGB sync prob (quoted above) as well as the black line artifact w/ half-n-half color prob I also mentioned appear to be tied to the DMA transfer address. In particular, its the modulo of the transfer address with 4 that's the ticket: addr % 4 == 0 - Looks good addr % 4 == 1 - Vertical black line up center of window; left side colors fine; right side is blueish (RGB off-sync w/ framebuf right of center) addr % 4 == 2 - Vertical black line up center of window; left side blueish; right side greenish addr % 4 == 3 - No vertical black line; entire window greenish To duplicate, uncomment the 2 printfs around tvcapture.c line 1490 and run "fxtv -geometry +<x>+<y>" with some permutations of <x> and <y>. Randall
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970929213602.53357>