|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 04:16, Ville SyrjÃ¤lÃ¤ wrote: > On Sun, Dec 08, 2002 at 03:59:12AM +0500, Antonino Daplas wrote: > > On Sat, 2002-12-07 at 14:27, > > firstname.lastname@example.org wrote: > > > PIII-600. That should be fast enough I would think. > > > > > Depends on the data. Should be fast enough for VCD like mpegs, but DVD > > needs a very fast bus/CPU. > > 600 MHz Duron seems to be more than enough. Actually about a year ago I > still used XFree86 dualhead with software color conversion and scaling to > play DVDs/DivXs on my TV. I think it was just enough to get it done. But > any other activity caused dropped frames. Oh the horrors of those months I > suffered with that crap. > Ok, I presume it was enough if you have hardware scaling. > > 2. Waiting for vsync does not necessarily mean that the actual flip has > > occured. If this happens, mplayer may begin writing to the same buffer > > that is in the process of being flipped (can cause shaky display, or > > visual artifacts). In some hardware, there is an extra flag which says, > > "yes a vsync has occured, but I'm only setting this flag after the > > actual buffer flip". I don't know about matrox hardware, but maybe > > there is one like that. Or just wait for the end of vblank, since the > > end of vblank occurs some time after the end of vsync. > > The docs only say that the changes in the registers become active after > the beginning of the next vertical blank. Nothing else. Ok. > > > 3. Direct rendering to video memory might not be the correct way to go, > > not just for reasons 1 and 2. It's better if the mplayer backend do the > > processing of video to a temporary buffer in system memory, instead of > > directly to video ram (This is how Xvideo does it). At first glance, it > > might seem slower, but mplayer may read the contents of the previous > > buffer (for hardware MC, or whatever?), and video memory reads are > > 10-20x slower than writes. > > We aren't writing to video memory. The temporary buffers are allocated > without specifying their location. Thus they are allocated in system > memory and are copied to video memory as needed. And DirectFB should make > sure the the copy is complete before the blit happens. Ok. > > But perhaps the blit hasn't completed when we flip the buffers... Ok, I > admit to being an idiot. When I added the vsync stuff I copied it straight > out of the fbdev stuff without thinking. The gfxcard_sync(); is totally > misplaced. Obviosly it should be before programming the registers not > after. I attached a patch to fix this. > This depends on the hardware though. In some hardware, flips are automatically done during vblank, thus you can actually program the registers then wait for vsync (or not wait at all). This one is perfect for mplayer since it already regulates the frame rate via time stamps, and flips are automatically done during vblanks without additional CPU penalty. In others, flips are independent of vblank/vsync (async flips). In this case you have to wait for vsync, then touch the registers to avoid tearing effects. Yours is most probably this case. This is precisely the reason I asked for further differentiation of the wait_for_vsync flags in a message I sent some time ago. Tony -- Info: To unsubscribe send a mail to email@example.com with "unsubscribe directfb-dev" as subject.