Date: Mon, 20 Apr 1998 06:26:33 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, Amancio Hasty <hasty@rah.star-gate.com> Cc: sos@FreeBSD.ORG, jerry@freeside.fc.net, multimedia@FreeBSD.ORG Subject: Re: problem capturing video with BT848/Haughpage Win/Tv Message-ID: <19980420062633.B9931@ct.picker.com> In-Reply-To: <199804200255.EAA13572@labinfo.iet.unipi.it>; from Luigi Rizzo on Mon, Apr 20, 1998 at 04:55:31AM %2B0200 References: <19980419180420.D8034@ct.picker.com> <199804200255.EAA13572@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo:
|> 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
|
|now i understand why it gets slower... so you don't use the clipping
|code in the driver ?
Right.
|is there any app. actually using it ?
Not sure.
Amancio Hasty:
|This is a flaw in the current X server protocol model. It can tell you
|what happened now what is about to happened .
|
|The Bt848 clipping code belongs in the X server along with a video
|capture extension to the X server.
Luigi Rizzo:
|> This is a flaw in the current X server protocol model. It can tell you
|> what happened now what is about to happened .
| ^^^ i assume this is "not"
|
|you mean that you know that a window is occluded but don't know what
|parts of the window are visible and what not ? (or it would be a lot of
|work to scan through all windows and determine the shape of the visible
|area, duplicating the work already done by the server ?)
Exactly. There are two design issues that make it impractical from an X app
standpoint.
First (as you mentioned), there isn't a decent event-driven way to keep an
exposed region definition up-to-date with X (polling the X server's
complete window list every 10th of a second doesn't qualify :-); it isn't
practical and wouldn't work solve it completely anyway).
Second, X dispatching to clients is asynchronous so by the time you get the
heretofore unknown "here's-your-exposed-region-definition" event, that
region definition has already changed, and starting capture with that
region definition may stomp an occluded window.
Likely a similar issue exists with MSWin as the Hauppauge software forces a
refresh of the entire screen just about everytime anything window-event
related happens anywhere on the screen, on the off-chance something got
stomped by the direct framebuffer writes.
As far as purely technical issues for using clipping, back when I worked
with Amancio's clipping in Oct 97, there were a few bugs related to the
clipping. But these are easily solvable and Amancio may have fixed them
since then:
Started trying out the bktr clipping half hour ago and noticed a few
small bugs. My tests have been very minimal, but so far what I've
noticed is that the driver seems to swap X and Y (X and Y defined per
display convention and as X does), and the Y coordinates (X, with the
swap bug) are doubled when capturing both fields. The latter's
probably just a loop stepping typo.
For example, with this clip rect:
(X 10, Y 50) - ( X 20, Y 100 )
with single field, what gets clipped is:
(X 50, Y 10) - ( X 100, Y 20 )
and with double field, it's:
(X 50, Y 20) - ( X 100, Y 40 )
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?19980420062633.B9931>