On Tue, Dec 18, 2001 at 10:41:30AM -0800, Billy Biggs wrote:
> >
> > So yes it works very well even without interrupt driver with just poor
> > linux scheduler - but of course tearing is unvoidable in this case...
>
> Tearing is totally avoidable without a kernel vsync device! Like I
> mentioned in my email, the Xv drivers for nVidia cards, i810 chips, and
> ATI cards all double buffer and don't flip until the next retrace!
I'm talking about current situation with my card - I don't know
who some other cards perform - so of course if in the future the
double buffering will be fixed there will be no such problem :)
> > > For example, many CRT projectors can run at 72hz which is great for
> > > 24fps video. To ensure a 3-3-3-3 pattern we must have a vsync
> > > device.
> >
> > I would say we need better kernel :)
>
> Why? One with vsync devices for all video cards or one with lower
> scheduling latency?
With both - the problem is - NVidia would have to support such device
and Linus would have to think more about multimedia support :)
> > Well I do not have 60fps material :) I do use 29.97Hz movies... I'm
> > currious what do you mean by 60fps material - do you use some high
> > speed video cammeras :) in my eyes there is no such thing like 60fps
> > video - movie has 23.97, PAL 25, NTSC 29.97
>
> If you deinterlace a 29.97fps NTSC stream you get 59.94fps video, each
> field gets expanded to a frame.
Well I've though that you will just pass one image and leave the
graphics card to do the rest - are you suggesting you are pushing
two different images into the graphics card ?
(If yes then why ???)
> > > Do what itself? Tell you if you're on an odd or even field?
> >
> > No I mean - I'll give two following images and video card would be
> > doing proper interlacing...
>
> I'm sorry, I don't know what you mean.
I mean that video card might have support for some simple
interlacing itself.
e.g. You have image which shuold be displayed for some period of time -
but for TV output this image will be displaye in this way -
first pass - show every odd line
second pass - show every even line
third pass - blend current odd lines with odd lines from the second image
fourth - show even lines of second image
fifth - show odd lines of the second image
....
and this would depend how odd/even frames are comming and how fast the
video should be displayed - e.g. it would be some simple way
to mimic interlace support (which however would require much more
complicated algorithms)
> > fast for every video application thus we do not need to modify kernel
> > :) to fix latency problems
>
> Do you have a link to him saying that? A vsync device would be
I'll try to find - but somehow I could not locate it for now :(
But I believe I've saved this samewhere...
> sufficient, and Alan Cox is apparently willing to put it in the kernel
> if the code is written.
Well I've been already discssing this with him for several times.
> > I think that the need for vsync device is know for a long time and yet
> > there has nothing (except for my completely ignored attemp)
>
> How much did you publish your attempt? I just learned that your
> mga_vid had been modified. Regardless, there is interest now I think we
> just need to write the code. I'm currently modifying your mga_vid
> module to be a little more generic and I'll try to code support for
> i810.
Yeah - it should be written completely diferently and moved outside
of the mga_vid - I've used this just that I do not have to write whole
code around :)
But as I said - it would require some general kernel lock for accessing
hardware registers of the graphics card - as XFree is running in the user space
and doesn't use spinlock to prevent manipulation with the hardware
register. I guess I've posted some email on LKM about this - without
any interest. I've been also discussing this a bit with Alan, but
when he said there are some people working on this kind of device I've
decided to wait what they will invent (and I've been quite dissapointed
that /dev/vbi is already taken - so only /dev/vsync is left :))
Ohh I guess I should also release my few patches for BTTV - as somehow
I could not convince bttv author to include this code in some form into
his driver - thought I'm quite currious why just people do not complain
about these missing features :)
--
.''`. Which fundamental human right do you want to give up today?
: :' : Debian GNU/Linux maintainer - www.debian.{org,cz}
`. `' Zdenek Kabelac kabi@{debian.org, users.sf.net, fi.muni.cz}
`- Resistance is futile. You all will be packaged
_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile
