On Sun, Sep 23, 2001 at 04:52:24PM +0200, Matthias Dahl wrote:
> > As he also pointed out that hardware automatically does this.
> That depends on the hardware - matrox cards unfortunately don't do this
> automatically. And I guess if it did, some people would complain about
> it because they want the best possible frame rate. :(
Well, you can't get higher frame rate than your monitor can go can you? Unless
your brain is plugged directly to the videoram :-)
> Maybe I am wrong but I don't think your TV out does need to synch with your
> TV - and I don't know if this is possible at all.
Actually I don't know that much about TV either. But TV is similar to monitor
in that both are CRT-based. So the signal is generated the same way and indeed
you should need to sync drawing.
> As far as I understand it those tearing artifacts are caused by different
> frequencies (your video material is 29.xx fps but your monitor for example
> runs at 68 Hz)
I don't think so.
> and the different "formats" (your monitor is usually a progressive
> display while your TV is a interlaced display
My current theory is indeed that this is something with interlacing. I believe
that my routine simply waits for A retrace, and not a FIRST retrace of the
two, hence the 2 pictures sometimes overlap.
> - I hope I am not making a fool out of myself and those things I just
> said were right!).
I believe you are partially right.
> So your TV out should now deliver the frames in the right frequency (50Hz
> for example) and in the right format (interlaced). That should be it. So
> IMHO your are looking at the wrong thing to find the cause for your
> problem...
I still think that the problem is caused by retraces not being synced to data
transfer. It doesn't matter that the frequency is lower or it is interlaced,
you can't expect the picture to look ok if you transfer data to videoram while
the ray is drawing.
> Yet I think this could cause a bit of trouble. If your system is under
> heavy load, you could easily miss the right time.
Well, that's why we have patches for preemptive kernel and low latency.
Unforutnately the preemptive patch causes crashes and segfaults pretty often,
so I'm sticking to lowlat.
For more than 75Hz I don't think you'll notice a difference whether a picture
is displayed on 2 or 3 frames. Otherwise the latency would have to be bigger
than about 1000/75/2 = 6ms and I don't think that happens even if load is
high, unless you are too low on memory and in that case disturbances are
expected to occur anyway.
> So the function that is responsible for drawing the image waits even longer.
It doesn't matter, it still looks better than 2 pictures mixed together.
> On the other hand it's a step in the right direction (a quick workaround).
> :-)
Sure.
> Now what confuses me is that I thought it isn't possible to get the retrace
> information in user space - just in kernel space. I guess this is only true
> if you want to make use of the hardware interrupt that is being issued (and
> naturally that would be the best solution IMHO).
I think you're right on this.
> But I still think there should be an official way (through the kernel space
> drm drivers for example) to get that information and handle it in the right
> functions (for example XvPutImage) by implementing an optional double
> buffering that is only used if a) retrace information is available and b)
> if the programmer explicitly asked for the feature.
Hmm mga has some buffering stuff like this in hardware I've heard.
> Thanks for the hint. I have tried avifile some time ago and was pretty
> pleased with it. But now XINE has become my player of choice where I'm also
> trying to contribute a bit. :)
I find xine cubersome to use, in fact I was unable to actually get it working
:-) Of course everyone will claim their player is the best <g>.
> Last but not least. Could you please cc your answers to my mail address
> because I am not subscribed to the Xpert list - just using the archives. :-(
k
> So long, Matt ]) [EMAIL PROTECTED], GPG key available at public keyservers ([
Bye,
Peter Surda (Shurdeek) <[EMAIL PROTECTED]>, ICQ 10236103, +436505122023
--
Secret hacker rule #11: hackers read manuals.
PGP signature
