|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: Seeing "tearing" using mplayer dfbmga
On Sun, 2002-12-08 at 16:25, firstname.lastname@example.org wrote: > On Sun, Dec 08, 2002 at 02:29:32PM +0500, Antonino Daplas wrote: > > > > [ disclaimer: I am no expert at all on G400 hardware. My statements > come solely from what I have learned from an expert or two ] > Neither am I. You probably know more about matrox hardware than I. [...] > > >From what I have been told, you can give the G400 a field interlaced > frame (a frame with both fields in it) and it will display the first > field, and then the second field, timed properly to the vsyncs. I > don't see a need for the front-end to wait for a vsync between those > fields. The video card does the work of making sure they are > displayed one after the other while the front-end goes on th prepare > the next field interlaced frame for the vsync that occurs after the > 2nd field is displayed. > Ahh, okay then. So the matrox hardware automatically displays an interlaced data stream to an interlaced display device without additional processing. >From what I know about this kind of hardware (which is not much), is that they are more sensitive to the overall system latency rather than CPU power. You probably know the latency condition of linux, it's not just the high latency, but the irregularity of it. You can easily compensate for high latency as long as you know it's constant, but a high latency range from a few milliseconds to a few hundred milliseconds is a killer. It's the way how each field is displayed by typical hardware. This may not be true with matrox hardware, but with interlaced data, the display of field 1 starts almost immediately after flipping the frame. The display of field 2, on the other hand, occurs at a fixed interval independent of the frame rate. The interval is determined by the system. For a PAL system: 25fps, 40ms/frame, 20ms/field. So field 2 is displayed 20ms after field 1 and whether the frame rate is decreased or increased, field 2 will always occur 20ms after field 1. Here is where latency comes in to play. Assuming that during waiting for vsync for Frame0, the signal arrived 20ms too late. Frame0Field1 therefore gets displayed at t20ms, and Frame0Field2, at t20ms+20ms = t40ms. Next, you wait for vsync for Frame1, but this time it gets delayed by only 5ms. So Frame1Field1 gets displayed at t45ms. However Frame0Field2 is still being displayed by the hardware, and this can cause visual artifacts. This misordering/irregular ordering of the display of fields is probably not noticeable if the scene is slow-paced (delta between fields is small). However, with fast-paced scenes (delta is high), that's when you see tearing, unusual artifacts, etc. You will also notice that not a single frame is actually dropped, and all these artifacts can be accounted for by irregular delays during the display process. This is one of the reasons why frame based data is so much easier to display properly (because you can always choose to wait or drop frames depending on the time delay). This is a bit problematic with interlaced data because of the presence of fields, and worse with NTSC systems which has a lower frame interval of 33ms. Anyway, all of the above is moot and academic if you do not use IRQ's when waiting for vsync, or if the matrox hardware drops delayed fields automatically. Polling the registers directly, although it consumes a lot of CPU cycles, suffers almost no latency penalty. So, if you are doing this already, then disregard my entire post and consider it as a waste of bandwidth. Tony -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.