Smooth as butter

I downloaded some 720p and 1080p trailers to test under Ubuntu in my new laptop, but Xv would crash and no video player was able to playback them. For large video resolutions you need this on your xorg.conf if you are using the i810 driver, or you’re toasted. Small-sized videos work fine out of the box.
Option VideoRam XXXXX (write how much VRAM you got)
Option CacheLines 1024 (use more if the video has more vertical lines)

So, after my changes I restarted X and what do you know? 1080p video is smooth as butter on this 1.66 Ghz CoreDuo laptop with 1 MB cache! If I had opted for the 2MB cache/2.0 Ghz Core2Duo instead the speed would have been considerably better even! It’s cool, because my other laptop, a 2.8 Ghz P4 and even my desktop a hyperthreaded 3.0 Ghz P4 can’t render 1080p without dropping frames! It’s amazing what Intel and AMD have accompliced the last few years without having to continue that pointless megahertz race!


Luis wrote on March 15th, 2007 at 2:19 AM PST:

Videos with higher resolution than my screen (1024×768) always crash my video player. Adding those lines you suggest didn’t change the situation.

My “trick” to be able to watch these videos is to change the output driver from Xv to X11/Xshm. With that driver I can watch them, but still with high cpu usage and dropping some frames (I have a P4 2.6 Ghz).

I guess it’s not possible to create a codec that’s both “bandwidth friendly” _and_ “cpu friendly”. At least there should be both alternatives, but all modern codecs seem to go for higher compression at the cost of higher cpu usage.

This is the admin speaking...
Eugenia wrote on March 15th, 2007 at 6:06 AM PST:

Luis, this seems to be a bug in your driver, these lines should have helped you out with Xv. Without Xv, you don’t get proper acceleration and speed. Maybe that’s why your glxgears are not faster than that too. Which chipset of Intel’s cards do you have, how old is the driver, and how much VRAM? Let me know and I can send you my xorg.conf too, it might help.

Moulinneuf wrote on March 15th, 2007 at 7:11 AM PST:

Cache , ram and size , seem to always be behind for some reason even FSB.

Rarely do we see cache above L2 , ram size is almost always around 2Gig , and FSB , the CPU speed and MHZ change , but the FSB is almost always in the low 1ghz. Its more self evident in technical listings.

On the other end CPU have really improved so do graphic , screen , keyboard , scrolling device , mouses , Hard drive , but with hard drive again the cache and on device memory have just recently improved. Wifi , bluetootht. etc …

if you look at the original celeron its major flaw was no cache , as soon as they did add cache like previous CPU it started behaving better.

Add more cache should be the vendor priority and not settling for same or inferior cache should be what customer are on the look out.

Luis wrote on March 15th, 2007 at 7:24 AM PST:

My chipset is an Intel 845G with 64 MB shared memory. I’m running the latest driver from xorg (xf86-video-i810-1.7.4). I never before tried the “CacheLines” option, so don’t know there might be a bug about it. But the glxgears can’t be a configuration or driver problem, since I’ve tested dozens of distros here in the last 3 years with similar results (as I said, only the changing the Colour Depth gives me a boost).

DRI is obviously working. If I disable it there’s no way I can use Google Earth, for example.

It *is* strange that I can’t play high resolution videos with Xv but I can with Xshm, but I never cared much to about it since I don’t usually watch videos anyway.

My xorg.conf:

Section “Device”
Identifier “** Intel i810 (generic) [i810]”
Driver “i810″
VideoRam 65536
Option “CacheLines” “1024″

This is the admin speaking...
Eugenia wrote on March 15th, 2007 at 7:53 AM PST:

Luis, please replace your Module and Device section with these and retry and Xv:

Section “Module”
Load “bitmap”
Load “i2c”
Load “dbe”
Load “ddc”
Load “dri”
Load “extmod”
Load “freetype”
Load “glx”
Load “int10″
Load “vbe”
Load “Xrender”
# Load “GLcore”
Load “v4l”
Load “fbdevhw”
Load “record”
Load “type1″

Section “Device”
Identifier “** Intel i810 (generic) [i810]”
Driver “i810″
Option “RenderAccel” “true”
Option “VBERestore” “true”
Option “XAANoOffscreenPixmaps” “true”
Option “DRI” “true”
VideoRam 65536
Option “CacheLines” “1024″

If you copy/paste the above make sure you change the smart quotes to double quotes, because this blog auto-changes them when you submit a comment.

The above configuration works for me when I try to play large videos.

Luis wrote on March 15th, 2007 at 8:24 AM PST:

Thanks, Eugenia. I just tried it, but it still crashes. However, I think I found the reason. Starting mplayer from a terminal I get this message:

[xv] Source image dimensions are too high: 1280×544 (maximum is 1024×1088)
FATAL: Cannot initialize video driver.

So it seems that my Xv driver can only do up to 1024×1088. Don’t know it that’s related to my screen resolution (1024×768) or something else. My monitor can do higher resolutions, so I’ll try with 1280×1024 and see if that works.

This is the admin speaking...
Eugenia wrote on March 15th, 2007 at 8:38 AM PST:

Hmm, yeah, weird it doesn’t work. You can revert mplayer to use the X11 output by editing in ~/.mplayer/config and change to “vo=x11″

BTW, are you using the latest i810 driver from xorg? Ubuntu updated their i810 driver to a new one just a few days ago you see.

Also, I assume you restarted the X server after making the suggested changes above, right?

Luis wrote on March 15th, 2007 at 11:04 AM PST:

I prefer to have Xv as the default output driver since it’s more efficient than X11, and just change to X11/Xshm if I need to watch a video with higher resolution.

I’m using the latest stable driver (I use Arch, not Ubuntu, so I’m not sure if Ubuntu is using a development one). And yes, I restarted the X server.

I’m not sure where the 1024×1088 limit comes from, but changing my monitor to 1280×768 had no effect. I think the limitation is from my graphic card.

However, I found the solution. If I have a 1280×544 video, I have to use this:

mplayer -vf scale=1024:436 myvid.avi

And it works like a charm ! No frames dropped, not excessive cpu usage. Great !

Now I think I’ll file a bug/wish to mplayer. If they can detect that the highest resolution allowed for my card is 1024×1088 and they detect that the video I’m trying to play has a higher one, it would be very nice that the player scales the video automatically instead of crashing.

Thanks for your help. I never cared about solving this problem since it never bothered me much, but it’s great to know I will finally be able to watch HD vids smoothly when I want it :)

This is the admin speaking...
Eugenia wrote on March 15th, 2007 at 11:30 AM PST:

Luis, bug report here.

Luis wrote on March 16th, 2007 at 12:01 PM PST:

I read that thread, but my problem is not the same. I don’t get that “BadAlloc: insufficient resources” error. Technically my system works correctly. See, if I run: “xvinfo | grep max”, I get: “maximum XvImage size: 1024 x 1088″. Videos below that limit play just fine (unlike the problem described in that thread).

What I now found is that I can even play videos *above* that (hardware?) limit by only scaling them down (and without adding CacheLines to xorg.conf either). All I have to do is *manually* downscale the resolution to fit into that limit. It’s just a usability problem. I think that the player should do that automatically instead of just quiting and leaving the user without his video. I’ll report to mplayer and see what they say.

Comments are closed as this blog post is now archived.

Lines, paragraphs break automatically. HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

The URI to TrackBack this blog entry is this. And here is the RSS 2.0 for comments on this post.