> On Saturday, 29.11.2008 19:34:04 Oliver Seitz wrote: > >> Most important, you did not say what -vo you're using or if you`re >> scaling >> the video. > > I don???t specify -vo, letting mplayer choose. It chooses xv. Which -vo is > the > fastest? -vo xv is not a bad choice in general, and it does scaling on your NVidia, not on your Pentium, if you're using an NVidia-(open source or proprietary) driver. >> If you e.g. use -vo x11 and zoom in software, that probably won't work >> well with HD on any machine, may it be as fast as light. > > One of the videos is 1280 by 700something, which matches my 1280 by 1024 > monitor exactly. But it desynchronizes as well. > >> I would check the way the decoded video reaches your hardware first, not >> the decoder side. > > I???m not sure I fully understand that. How do I perform such a check? Well, the video is read from your hard disk, decoded, possibly filtered in some way, and then sent to your graphics card. Each of those actions can perform badly. If you play the video from an external harddisk connected via USB1.1 or from a file server via 10MBit network, that would likely be the problem. If your graphics card is a PCI one, the decoded video with a data rate of something like (1280*700*3*25=) 65MByte/second requires half the absolute maximum bandwith a PCI bus can provide shared for all devices. This would be unlikely to work smoothly. The easiest thing to find out might be if it's MPlayer's decoding and filtering or data movement what causes trouble. Just take a look at "top" when playing a video. In the CPU status line usage is summed up where the decoding and filtering will add to the "us" number, while writing to the NVidia should increase the "sy" number (but I'm not really sure about this) . Reading from USB, HD or network will increase the "wa" number. If both "sy" and "wa" stays at about or below 10% while "us" is in the 80s, it's really MPlayer that doesn't run fast enough. Greets, Kiste
