I like to watch mkv x264 video files of 1280x720 resolution. Unforunatately, they start lagging after 10 minutes of playback. The CPU usage just silently goes up around....20 or so percent. Stopping the video and restarting causes it to become smooth and normal again. To the best of my knowledge there are no errors in the mplayer log.

My computer is an AMD 3500+ with 2 gigs of ram and the video card is a Geforce 6800 Ultra (evga manufactured). I'm using kubuntu Hardy, 64 bit verion. Currently I am using MPlayer SVN r27243, and the x264 driver is the newest one I could find on the VLC webpage. I had the exact same problem using the default MPlayer installed via Synaptic. Usually I use compiz, but this problem is present even with it off. Even logging into fvwm-crystal does not fix the issue.

I prefer using SMPlayer as a front-end, but using it, MPlayer without gui, or MPlayer with gui has no effect; this problem is always present.

This issue is driving me crazy since I have absolutely no idea what the cause is (I've tried different video drivers including x11, xv, gl, and gl2).

Messing with video settings doesn't seem to fix anything either.

Any help would be appreciated.

Apparently if I let it play for a long time, it gives me this message:

Too many video packets in the buffer: (504 in 8403432 bytes).
Maybe you are playing a non-interleaved stream/file or the codec failed?
For AVI files, try to force non-interleaved mode with the -ni option.


ad infinitum

I would try the -ni option after seeing that message. Aside from that, there are things you can do to make sure your computer is optimized for multimedia playback. The details are here under "Smooth Playback:"
http://freshmeat.net/articles/view/747/

The section under Smooth Playback talks about why and how to use
/proc/sys/dev/rtc/max-user-freq

This info is from
http://www.mplayerhq.hu/DOCS/HTML/en/mtrr.html :

~~
It is VERY recommended to check if the MTRR registers are set up properly, because they can give a big performance boost.

Do a cat /proc/mtrr:

--($:~)-- cat /proc/mtrr
reg00: base=0xe4000000 (3648MB), size= 16MB: write-combining, count=9
reg01: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=1

It's right, shows my Matrox G400 with 16MB memory. I did this from XFree 4.x.x, which sets up MTRR registers automatically.

If nothing worked, you have to do it manually. First, you have to find the base address. You have 3 ways to find it:

1.

from X11 startup messages, for example:

(--) SVGA: PCI: Matrox MGA G400 AGP rev 4, Memory @ 0xd8000000, 0xd4000000
(--) SVGA: Linear framebuffer at 0xD8000000

2.

from /proc/pci (use lspci -v command):

01:00.0 VGA compatible controller: Matrox Graphics, Inc.: Unknown device 0525
Memory at d8000000 (32-bit, prefetchable)

3.

from mga_vid kernel driver messages (use dmesg):

mga_mem_base = d8000000

Then let's find the memory size. This is very easy, just convert video RAM size to hexadecimal, or use this table:

1 MB = 0x100000
2 MB = 0x200000
4 MB = 0x400000
8 MB = 0x800000
16 MB = 0x1000000
32 MB = 0x2000000

You know base address and memory size, let's setup MTRR registers! For example, for the Matrox card above (base=0xd8000000) with 32MB ram (size=0x2000000) just execute:

echo "base=0xd8000000 size=0x2000000 type=write-combining" > /proc/mtrr

Not all CPUs have MTRRs. For example older K6-2 (around 266MHz, stepping 0) CPUs don't have MTRRs, but stepping 12 does (execute cat /proc/cpuinfo to check it).
~~

For me, the skipping lessens if I use the x11 driver, but after setting up the mtrr you should be watching these files with perfect quality.

I set up the mtrr...it seems to be correct...however, the problem is still present.

Tried -ni as well...no change....

10 minutes might be a bit inaccurate, as it seems to be somewhere between 5 and 10 minutes.