|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 Fri, Dec 06, 2002 at 08:32:16PM -0500, email@example.com wrote: > > Altough I'm not sure > > the symptoms would be clearly visible with PAL timing. But wouldn't hurt > > to try. > > Can you even play an NTSC coded MPEG on a PAL set? Sure. The only real difference is the frame rate. It's just a matter of dropping some frames to display "NTSC" MPEGs on a PAL display. And duplicating some frames if you want to do it the other way around. > > But if you run mplayer without '-nosound -benchmark' > > it throttles the output. > > "Ties up" the process for the duration of the (double field) frame you > mean, which has the effect of missing the vsync between the two fields > within the frame it's holding for? Missing every other vsync would be harmless since mplayer only deals with complete frames. > > The ioctl is only used when we want an > > interrupt. > > Right. And since MPlayer ties up the process, we only end up getting > the one that happens between Mplayer's frames, not between the two > fields that are in a frame? Am I right? Yes. > > If you move the calculation to the irq handler > > Rather than the IOCTL? Yes. > This talk of "throttling" output. Is it possible that MPlayer is > holding up the process for too long and we are somehow miss the vsync > between frames, and playing the same frame twice, in some cases? Possible and likely if your computer isn't fast enough. > What does MPlayer do exactly to throttle? Time how long it has taken > to decode a frame and load it up and then actively go to sleep for the > difference between the last frame interval, decoding time and the next > frame interval? Yes. A major factor here is the audio since glitches in the audio stream will be nasty whereas dropping/duplication the occasional frame will not matter much. > Or does MPlayer just do it's work and wind up getting blocked trying > to access something if it can go faster (which it has to of course, or > it will drop frames itself) than the display frame rate? What is it > that MPlayer is trying to access that it gets blocked from? That too. It sleeps while we're waiting for the interrupt. And this is not very nice when the computer isn't fast enough. In the worst case the process ends up sleeping one whole field. Time that could have been used to decode the next frame. Triple buffering would solve this problem. Fortunately we already have sort of triple buffering in dfbmga since we decode to an offscreen surface and blit from there to the backbuffer. I have a patch for mplayer that creates another thread which will do the waiting and let's the main thread keep on decoding. Unfortunately sometimes it breaks down mysteriosly so I haven't submitted it. > I understand that the G400 is double buffered, so that the > "back" buffer can be written to while the (front -- is that the right > term?) is being displayed. Well there's nothing really special in the hw wrt double buffering. We just tell the hardware to look for the data somewhere else. We just have to make sure not to flip the buffers while the hardware is reading them in the middle of the screen. Fortunately the registers involved will do this for us but we still have to make sure that they actually have flipped before we start writing to the new back buffer. Thus we wait for the irq after flipping not before. > Is there some kind of semaphore or > something that gets cleared when the card has moved the back buffer > contents into the front buffer and it's safe to write into the back > buffer again? Could MPlayer being missing this event and not writing > the next frame into the back buffer perhaps? No. The kernel just puts the process to sleep and wakes it up when irq arrives. -- Ville Syrjälä firstname.lastname@example.org http://www.sci.fi/~syrjala/ -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.