Zdenek Kabelac ([EMAIL PROTECTED]):

> > > 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 :)

  Luckily, Mark Vojkovich of nVidia has already stated he'll support a
vsync device if there is a standard API, and so many people are
demanding a lower HZ value in the kernel it has to happen sometime.

> > > 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 ???)

  You mean hardware deinterlacing?  Not all hardware can deinterlace,
and you can do a better job of it in software in many cases (such as
adaptive 3:2 pulldown detection, which I do in movietime).  For some
discussion and code about deinterlacing, a neat (windows) project is at
http://deinterlace.sf.net/

  My first attempt under linux is here:
  http://www.dumbterm.net/graphics/tvtime/

> > > 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. [...]

  This could be better handled by the software.  I believe we either
need an API where we give a stream of fields or frames with decided
dominance.

> > 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.

  Great, you and Erik and I'm sure others.  I think it's time to write
code.

> 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 :)

  I just started to play with your code.  I ripped out all the BES
stuff, now I'm looking at doing the same code for i810.  Sound good?

> 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.

  Ugh.  What about using the DRM?  Can we put locks in there?  I have no
idea about any of this DRI stuff or how that architecture works.

> 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 :))

  I don't believe anyone is actively working on it.  If there is we
should hunt them down and work with them.

> 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 :)

  What patches for BTTV?

  I complain on video4linux-list, but any time I bring up quality issues
(for example, the v4l X module only shows a single field!) I get flamed
as if I'm the only one who cares about these issues.

  Some help would be appreciated. :)

-- 
Billy Biggs
[EMAIL PROTECTED]

_______________________________________________
Avifile mailing list
[EMAIL PROTECTED]
http://prak.org/mailman/listinfo/avifile

Reply via email to