On Mon, Dec 17, 2001 at 02:57:10PM +0100, Zdenek Kabelac wrote: > You know that you just have to build device which > will generate vertical blank interrupt (vsyns) singal to wakeup video > renderer thread. You haven't probably read my original posts. Not tearing is the problem (ati drivers handle this). Some things in this "judder" thing the other guy wrote about, seem to describe my problem however, but my problem isn't how to do movie -> monitor but movie -> TV fps conversion.
Actually the M$ document seems to be pretty intelligent, try to read it to understand my problems. > already done - check /dev/mga_vid opening ...but as I said, not enough. > > - modify soundcard frequency based on these numbers and movie fps > no way - I would not accept anything based on Sound card - we have > VIDEO player and there are videos without sound which have to be played > (we can't tell user - hey add some soundtrack to this movie :) Note: there is NO OTHER way to smoothly play back 23.98 fps video on a 25 fps display (PAL TV). > > Simply telling the player "when you think you should draw, simply wait for > > refresh in addition to the stuff you usually do" doesn't solve the problem, > Yes it solves - at least for aviplayer. No it doesn't. > wait for #VBI 3 4 3 3 4 3 3 4 3 3 .... This may work for a CRT monitor that does like 80fps. But my PAL TV does 25. And when using tvout, it looks like this wait for #VBI 1 1 1 1 1 1 1 2 1 1 1 1 1 ..... This is what I'm talking about! And yes, you can SEE the difference between 2 and 1, it is obvious and disturbing (and by no means am I a hifi freak). And, because we don't have exact scheduling anyway, it also happens when playing a pal movie on pal fps (25@25) If you play ntsc video on pal tv (29.97@25), even with imperfect scheduling the results seeems to be mostly ok, it should look like wait for #VBI 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1 So basically the time between the frames you see is always 40ms. You wouldn't be able to see all the frames under this conditions anyway. > note - it already works this way with matrox card. Basically ati also worx this way. > > because the problem isn't that it draws too soon, but too late. > the player will never draw too late if the linux kernel would be doing > proper scheduling as well Yes it DOES, because in the case of TVout, in most cases you have to ensure the "2 wait for VBI" never occurs. This is what I'm trying to say: a method of ensuring a "x x x x x y x x x x" pattern that is calculated by comparing video and display fps, but we have to consider sound card speed. Please reread my original post, I think I explained my proposals for solutions more precisely there. Bye, Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023 -- /* vsprintf.c -- Lars Wirzenius & Linus Torvalds. */ /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */
msg02447/pgp00000.pgp
Description: PGP signature
