Dude, what's with the flame? Zdenek Kabelac ([EMAIL PROTECTED]):
> > 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 :) ??? Do I need to repeat myself? I know that using /dev/rtc is _not_ the right thing to do, it is some TEST EXPERIMENTAL CODE to show how better scheduling can affect amortization accuracy. > > 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... Of course not! I'm just telling of my experiences. I don't know what you're saying here at all: > > 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 It works without any external interrupt driver? What's mga_vid? :) > - with mga_vid you just prefent tearing effect - judder effect should > not be visible with decent monitor at all (e.g. vertical retrace > >=85Hz) Yes, I am working to avoid judder at refres rates less than 85hz! 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. Even worse, consider playback of 60fps material at 85hz. Judder is definitely an issue here! You have to run at 60hz refresh or 120hz refresh, and have an interrupt to drive your output. > > 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 > > 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. Dude, my sentence begins with 'Given we need a vsync device'. I say here that we need BOTH. Don't you agree? > > 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... Do what itself? Tell you if you're on an odd or even field? > > 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 I was just suggesting. LKM gets too much traffic, and this is definitely a video issue. I think you'll find more interested people there. > > 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. I don't think DVD support belongs in 'avifile'. I like it as a library for reading/writing AVI files, but I think you should split off your player if you want to go further. I think avifile handles too much of the sync issues itself. Regardless, it's lots of fun to write your own player. I think it's important that we work on common libraries but there is much fun in learning by writing your own. > 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. That's one way to do it. > 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. Showing the frame on the next refresh is fine so long as you are woken up at an appropriate time, but 10ms scheduling can screw you otherwise. Your other heuristics sound like quite a hack. :) -- Billy Biggs [EMAIL PROTECTED] _______________________________________________ Avifile mailing list [EMAIL PROTECTED] http://prak.org/mailman/listinfo/avifile
