Re: [Xvidcap-users] About, capturing the framebuffer...

[danalien <dan...@sl...>]

On Wednesdayen den 18 May 2005 11.08, Arne Caspari wrote:
> Hi all,
>=20
> Such a feature will ( almost certainly ) not go into unicap simply=20
> because it is not in the scope of such a library.

Well, I hand to ask, anyway.=20

as it would have been nice if Karl had some lib with good API's to make=20
xvidcap r0ck :-)

But, even though, maybe someone else might add support via the plugin-syste=
m=20
mentioned in the summary of unicap (on sf.net...) for 'static devices' too =
:-)
=20
> Having said that I would guess that simply capturing the framebuffer=20
> would be rather simple - this is what all the screenshot application do=20
> AFAIK. But it is a very slow way to capture the graphics since the=20
> framebuffer must be accessed via AGP which is too slow.

oh, I thought they hooked up to X ...


Q; is writing to the framebuffer (FBDev) as fast as reading from it?

=20
> The fast capture applications for windows hook up a mirror driver which=20
> mirrors all gfx requests such that the driver can capture the graphics=20
> without the need to read the whole frame buffer.

a 'mirror driver'? ... can that be done with non-f/oss drivers, eg, nvidia?

/* thinking only in linux here.. */


> Doing something similar on X you would need to use a mirror X server.=20
> While there are some,

got some more info about how? to read? ... googling didn't quite give the s=
ame=20
interpretation of the word 'mirror' :-) =20

> I do not know if any of them provides the required  functionality.=20
> At least this is a non-trivial task.=20



Karl H. Beckers wrote:
> Hi there Dan,
>=20
> for starters, I have no idea how the fraps people are doing their=20
> capturing. I'd very much assume that they hooking up to the DirectX=20
> stuff which on Linux would mean messing around with X11 or prolly=20
> libmesa or somesuch.

oooh oohh, I know, I know... they hook up some tiny, tiny, tiny mirrors to=
=20
their hardware, and copy/dumy *that stream ... =3D) j/k

> Though I would love to have such a feature, I don't think I'll ever=20
> start implementing that myself (because I'd never get to finish it ...=20
> as anybody who's following the progress of this project can confirm in=20
> light of the slim time I get to spend on it :( ) unless it comes wrapped=
=20
> in a handy API ...

yeah, as someone who has followed the project, one got the general hint
you might be a tad busy..

> Unicap might be one such API. Have you any smart ideas about this, yet?

As it turns out, it isn't one such lib/API :/.

though, one hope, might still exist if it's possible to craft a plugin usin=
g for unicap's
plugin-system, to support gfx-cards as 'capture devs...' :) =20

=2E.. but then again, one has to weigh in if capturing the frambuffer vs. t=
he 'mirror driver'
is worth the hassle...
=20
=2D-=20

//   with regards
//   UID ::  danalien  ::  <${gofigurewhatmyemailis}@slicker.org>
//   KID ::  0x446AA288

=2D - -
  /\/\
(^.^)
 (")")
 *This is the cute kitty virus, please copy this into your sig so it can sp=
read