|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 22:52, firstname.lastname@example.org wrote: > On Mon, Dec 09, 2002 at 01:01:15AM +0500, Antonino Daplas wrote: > > > > Neither am I. You probably know more about matrox hardware than I. > > Doubt it very much. :-) Ville on the other hand... > > > Ahh, okay then. So the matrox hardware automatically displays an > > interlaced data stream to an interlaced display device without > > additional processing. > > That is my impression. Check out this thread: > > http://www.directfb.org/mailinglists/directfb-dev/2002/07-2002/msg00099.html > > > >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. > > I seriously doubt my PVR is experiencing several hundred millisecond > latencies. I could always be wrong, but I am in doubt. > Unless you have a low-latency patch, or using RT-linux, you can never know. Latency depends on so many things that it actually led to a rewrite of the linux scheduler for 2.5 and inclusion of kernel preemption. Latency killers: console framebuffer disk activity and some more > > 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. > > How can the framerate be increased or decreased with fixed framerate > hardware like a television. The only way to do that is to duplicate > or eliminate frames as necessary to maintain the constant output > framerate. > This was just an example to say that field2 will be shown at a fixed interval after the arrival of field1, whatever the frame interval is. The change of frame interval may be due to delays in arrival of the signal to the process, or by simply unthrottling the frame rate itself . is where latency comes in to play. Assuming that during waiting > > for vsync for Frame0, the signal arrived 20ms too late. > > You mean the interrupt? The signal will always arrive at the right > time. The kernel may not deliver the interrupt for some time after > the signal arrives however. > Yes, the time interval from the arrival of the interrupt signal, waking up the process, returning from the ioctl call, to processing the registers. That was what I meant. Sleeping while waiting for an interrupt to arrive is very nice because it gives the CPU to another process. Very good for systems where CPU power and thoroughput is important. But this is not appropriate if the process needs to get the signal immediately, or at least timely, manner. The problem with this is during the wake_up(). Whether the process wakes up now or a few hundred milliseconds later depends on so many factors which the process nor the kernel can control. IE. If at the time of waking up, the current process using the CPU was not a nice player and it won't give back the cpu to the kernel, you get delayed. If there are a lot of tasks waiting to wake up ahead of you, you get delayed more. And if each of these tasks waiting ahead of you awakes, each will take a few more precious CPU cycles to process what it was sleeping for, and you get delayed more and more. And there is nothing the kernel can do, because it cannot preempt. The worst part is that that each time you sleep, the time you actually wake up will not be constant. It's actually better to have high, but regularly timed latency, than relatively small but irregularly timed latency. It's easy to compensate when latency is a known constant. A lot of the latency problems are being solved in linux-2.5 (O(1) scheduler, preemption, workqueues, CPU affinity, punishing CPU hoggers, rewarding nice players, etc) So, for things that are sensitive to latencies, you're better of polling the registers directly, even just for testing purposes. Athough it increases CPU usage a lot, it will factor out the latency part. > > 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. > > I don't think so. It is my understanding that the process is to load > frames into the display buffer prior to the vsync, as early as you can > in fact. You then tell the card where the image is. Once this is > done, processing is done until the vsync interrupt because the > hardware will take care to change to the frame you just loaded during > the vblank. The only way you could lose is that if you take longer > than two fields to load up the next frame. But MPlayer detects this a > drops frames if I am not mistaken. > The above is partly my point in the other thread. Do you program the registers before or after waiting for vsync? Because if you do it after, then that is another contributor to latency. My whole point in a nutshell: if thoroughput/bandwidth is important, sleeping on an interrupt is preferable. If latency is more important, directly polling the registers is preferable. Rule out the possibilites that can be eliminated easily first. Test for latency, then for bandwidth, and compare the results. If there is no change, you can probably start looking somewhere else, such as a bug in the code. Tony -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.