On Tue, Dec 18, 2001 at 08:52:57AM -0800, Billy Biggs wrote:
> I know that using /dev/rtc is _not_ the right thing to do, I was
It's not just that - it's completely broken idea - what will you
do on non ix86 platform :) ???
> scheduling improves accuracy for avoiding judder. For my testing, it
> allowed me to try vga sync with only using spin-on-0x3da. Of course if
busy loops have been already investigated by Arpi :) - blind way...
You can't afford to waste CPU cycles there...
> Note: I'm _just_ using /dev/rtc for avoiding judder! My i810 double
> buffers nicely, no tearing!
Have you checked avifile ?
It's really doing the best it can with current linux possibilities -
it simply can't be better (for now we are not talking about
interlaced TV output) and it works without any external interrupt
driver - with mga_vid you just prefent tearing effect - judder effect
should not be visible with decent monitor at all (e.g. vertical retrace >=85Hz)
> Given we need a vsync device, I'll assert that if Xv drivers always
> double buffer we're done (forgetting TV out for now). Agreed? So now
No I still would prefer to be interrupt driver - because the interrupt
will wakeup you process - that's what we need if the linux scheduller
has such poor behaviour otherwice - so we still need VSYNC device.
> to discuss if the 8 bytes ala mga_vid are sufficient. :)
I think for proper interlace support we would need also sign to
mark odd/even frame for TV (might be used the HZ 4byte sign bit)
but generaly I would expect XFree driver would be doing this itself
if it possible...
> How about the xfree86 list 'Xpert'?
They are developing XFree bloated monster :) and we are speeking about
kernel problems here :) - you simply need kernel device to use interrupts
> > E.g. how it works in aviplay - there is separate thread for decoding
> > and separate thread for video scheduling - so there are some images in
> > the queue - the first one is taken and send to the Xfree - then (with
> > my modified mga_vid device) it will wait for vsync and will send
> > XSync command which will flip desired screen - there is NO better time
> > then this. And as the video thread is running in PERFECT sync with
> > VSYNC there are no propblems with this technique [...]
>
> I don't follow what you're saying here. Are you saying this is
> perfect for no tearing, or no judder? Are you syncing audio to video
both
> retrace, or just ensuring that you always show frames on the next
> retrace? How do you handle audio when you're syncing to video? I found
> this to be an annoying issue in movietime.
In the first places - don't you want to join avifile project in add
you DVD mpeg support there ? - as there has been already many issues solved
after many many many hours of programming and I think you do not
have to reinvent the wheel again.
Now to the sync code - the evolution of this took around half a year to
this current stage (which is really quite unique)
The main element is - the audio & video are both synced to realtime
but as some audio card have broken clocks the audio thread is
allowed to modify internal realtime clock if necessary by some small steps.
Video scheduler places the image in the nearest possible time after the
timer has expired but also some other rules have to be preserved - e.g.
the two following frames couldn't be display without some delay and
few other tweaks - around 3 or 4 of them - you may check the source.
The code is designed in such a way it will work with/without VSYNC device.
--
.''`. 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
