Date: Sun, 19 Apr 1998 18:04:20 -0400 From: Randall Hopper <rhh@ct.picker.com> To: sos@FreeBSD.ORG, Amancio Hasty <hasty@rah.star-gate.com> Cc: jerry@freeside.fc.net, multimedia@FreeBSD.ORG Subject: Re: problem capturing video with BT848/Haughpage Win/Tv Message-ID: <19980419180420.D8034@ct.picker.com> In-Reply-To: <199804191831.UAA02048@sos.freebsd.dk>; from Sren Schmidt on Sun, Apr 19, 1998 at 08:31:05PM %2B0200 References: <199804191811.LAA02016@rah.star-gate.com> <199804191831.UAA02048@sos.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Sren Schmidt: |> Thats interesting are you using PAL or NTSC? | |PAL | |> This is a beautiful full-size snap shot taken with fxtv: |> ftp://rah.star-gate.com/pub/abc.ppm | |Hmm, when I do full-size fxtv coredumps with a SIGSEG when I hit the |snap button. In fact it dies very easy, just move another window |over it and WHAM fxtv dies with a SIGSEG.... That's interesting. I'd love to see a stack trace from an Fxtv-0.46 compiled with debug. In fact, mail me a gziped core file and your executable. My INBOX is big enough 8^) Also, please mention video card, XServer vendor/version/server, and xdpyinfo output. Thanks! I'm not surprised that "snap" and "window occlusion" both produce the same behavior. Both result in switching Fxtv to PCIcapture-to-memory-to-XImage conversion (as opposed to PCIcapture-to-framebuffer). The puzzler is why this behavior involves a core dump. I bet you'll see the same core-dump behavior if you run "fxtv -disableDirectV" to force XImage conversion from the get-go. Thanks, Randall 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?19980419180420.D8034>