Bug 2772 - XVideo fails with HD video; error: BadAlloc (insufficient resources for operation)
Summary: XVideo fails with HD video; error: BadAlloc (insufficient resources for opera...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: * Other (show other bugs)
Version: 7.0.0
Hardware: x86 (IA32) Linux (All)
: high major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: 10912
  Show dependency treegraph
 
Reported: 2005-03-19 12:59 UTC by Antoni Grzymała
Modified: 2009-05-20 05:25 UTC (History)
10 users (show)

See Also:
i915 platform:
i915 features:


Attachments
My xorg.conf (2.29 KB, text/plain)
2005-03-19 13:00 UTC, Antoni Grzymała
no flags Details
Output from xvinfo (1.92 KB, text/plain)
2005-03-19 13:02 UTC, Antoni Grzymała
no flags Details
My current Xorg.0.log (44.31 KB, text/plain)
2005-03-19 13:03 UTC, Antoni Grzymała
no flags Details
Out from emerge --info on my Gentoo system. (2.73 KB, text/plain)
2005-03-19 13:06 UTC, Antoni Grzymała
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Antoni Grzymała 2005-03-19 12:59:45 UTC
After upgrading from xorg 6.8.0 (Gentoo stable xorg-x11-6.8.0-r4) to 6.8.2
(Gentoo stable xorg-x11-6.8.2-r1) I started getting this error when using
applications with XVideo output (ie. all my video players):

BadAlloc (insufficient resources for operation)
serial 160 error_code 11 request_code 140 minor_code 19

This happens on mplayer used with -vo xv, (tried both mplayer stable and current
~x86) and totem. Xine shows only a blue screen and does not play the video so I
presume a similar problem shows up. I do not get the problem in mplayer with -vo
x11, so I presume XVideo is broken in this release.

This happens only when I play large clips. In particular the ones that I tried
were larger than my LCD video display (1024x768), all the small clips I have
around *seem* to play fine.

My video card is:

0000:01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M3
AGP 2x (rev 02)

I'm using the stock xorg r128 driver with DRI enabled.

A snippet of some sample output from mplayer:

VO: [xv] 1152x864 => 1152x864 Planar YV12 
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
aspect: Warning: no suitable new res found!
X11 error: BadAlloc (insufficient resources for operation)

I'm attaching some relevant files and configs.
Comment 1 Antoni Grzymała 2005-03-19 13:00:50 UTC
Created attachment 2149 [details]
My xorg.conf
Comment 2 Antoni Grzymała 2005-03-19 13:02:19 UTC
Created attachment 2150 [details]
Output from xvinfo
Comment 3 Antoni Grzymała 2005-03-19 13:03:41 UTC
Created attachment 2151 [details]
My current Xorg.0.log
Comment 4 Antoni Grzymała 2005-03-19 13:06:06 UTC
Created attachment 2152 [details]
Out from emerge --info on my Gentoo system.

This file might include some useful information for anybody reviewing this bug.
Comment 5 Antoni Grzymała 2005-03-28 14:58:17 UTC
Update. After reverting back to 6.8.0 (trying to get rid of the bug) it turned
out I'm still experiencing it. I just never tried playing very large video clips
before moving to 6.8.2 it seems. Anyway, this bug still bugs me and is valid, so
please take a look at this sometime.
Comment 6 FreeDesktop Bugzilla Database Corruption Fix User 2005-06-26 21:04:34 UTC
This bug appears similar to one at:

https://bugs.freedesktop.org/show_bug.cgi?id=474

The above bug has been repoened.

I am experiencing problems with XV unable to play high definition 1920x1080
video streams under mythtv. Lower resolution video streams play perfectly. When
displaying a HD stream, mythtv repeatedly reports: 

X Error: BadAlloc (insufficient resources for operation) 11
  Major opcode:  142
  Minor opcode:  19
  Resource id:  0x0

I am running linux-2.6.12-gentoo-r1, xorg 6.8.2, ATI binary Radeon X800 XL 256MB 
fglrx version 8.14.13, on a Pentium 4 2.4 GHz system.
Comment 7 Denis Vlasenko 2006-03-21 22:57:03 UTC
I have the same problem on a 256M ram box with xorg 7.0 and i815 onboard video.
I had tha same problem on home box (NVidia card there) with older X, but I
upgraded ram to 256M+512M and it stopped to happen. On to bug report.

Trying to run "mplayer -v valles3d_hd.wmv" says:
...
Starting playback...
lavc_audio: error
avg. framerate: 4 fps
*** [vo] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
get_path('subfont.ttf') -> '/home/vda/.mplayer/subfont.ttf'
New_Face failed. Maybe the font path is wrong.
Please supply the text font file (~/.mplayer/subfont.ttf).
subtitle font: load_sub_face failed.
[xv] dx: 0 dy: 0 dw: 1273 dh: 764
A:   4,0 V:   3,0 A-V:  0,974 ct:  0,000   1/  1 ??% ??% ??,?% 0 0
Type: 0, display: 873f910, resourceid: 1a00001, serial: 5c
Error code: b, request code: 8c, minor code: 13
MPlayer interrupted by signal 6 in module: vo_check_events
...

mplayer -v -vo x11, which does not use XVideo, works fine.

diff -u mplayer_xvideo.log mplayer_x11.log:

 Decoder is capable of YUV output (flags 0x1b)
 VDec: vo config request - 1280 x 720 (preferred csp: Packed YUY2)
 Trying filter chain: vo
-VDec: using Planar YV12 as output csp (no 0)
+VDec: using BGRA as output csp (no 3)
 Movie-Aspect is undefined - no prescaling applied.
-VO Config (1280x720->1280x720,flags=0,'MPlayer',0x32315659)
-VO: [xv] 1280x720 => 1280x720 Planar YV12
-VO: Description: X11/Xv
-VO: Author: Gerd Knorr <kraxel@goldbach.in-berlin.de> and others
-Xvideo image format: 0x35315652 (RV15) packed
-Xvideo image format: 0x36315652 (RV16) packed
-Xvideo image format: 0x32595559 (YUY2) packed
-Xvideo image format: 0x32315659 (YV12) planar
-Xvideo image format: 0x30323449 (I420) planar
-Xvideo image format: 0x59565955 (UYVY) packed
-using Xvideo port 57 for hw scaling
-[xv] dx: 0 dy: 0 dw: 1280 dh: 768
+VO Config (1280x720->1280x720,flags=0,'MPlayer',0x42475220)
+VO: [x11] 1280x720 => 1280x720 BGRA
+VO: Description: X11 ( XImage/Shm )
+VO: Author: Aaron Holtzman <aholtzma@ess.engr.uvic.ca>
+Sharing memory.
+SwScaler: using unscaled BGRA -> BGRA special converter
 INFO: Win32/DMO video codec init OK.
 Selected video codec: [wmv9dmo] vfm:dmo (Windows Media Video 9 DMO)
 ==========================================================================
@@ -145,25 +139,17 @@
 lavc_audio: error

 avg. framerate: 4 fps
-*** [vo] Allocating mp_image_t, 1280x720x12bpp YUV planar, 1382400 bytes
+*** [vo] Allocating mp_image_t, 1280x720x32bpp BGR packed, 3686400 bytes
 get_path('subfont.ttf') -> '/home/vda/.mplayer/subfont.ttf'
 New_Face failed. Maybe the font path is wrong.
 Please supply the text font file (~/.mplayer/subfont.ttf).
 subtitle font: load_sub_face failed.
-[xv] dx: 0 dy: 0 dw: 1273 dh: 764
-X11 error: BadAlloc (insufficient resources for operation)
-Type: 0, display: 873f910, resourceid: 1a00001, serial: 5c
-Error code: b, request code: 8c, minor code: 13
-
-MPlayer interrupted by signal 6 in module: vo_check_events
-MPlayer crashed. This shouldn't happen.

valles3d_hd.wmv is available at:
http://video.mars.asu.edu:81/valles3d_hd.wmv
http://128.100.103.4/mirror/mars/valles3d_hd.wmv
(you do not need to download all of it, just a few megs will do).
Comment 8 Xavier 2006-09-11 17:28:59 UTC
This looks like a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=2445
but I'm confused by the last comment from Matthew Tippett, saying it should be
fixed.
I also get the same problem with an intel 855 gm card and xorg 7.1 trying to
play Elephants_Dream_HD.avi available here :
http://orange.blender.org/download

mplayer crash with the BadAlloc error :
...
VO: [xv] 1920x1080 => 1920x1080 Planar YV12
...
X11 error: BadAlloc (insufficient resources for operation)

Xine crash with only : xiTK received SIGSEGV signal, RIP.

mplayer allow to scale down the resolution, and at 800x600 the movie plays fine:
$ mplayer -vf scale=800:600 Elephants_Dream_HD.avi
...
VO: [xv] 800x600 => 1066x600 Planar YV12
...

The limit seems to be somewhere between 800x600 and 1024x768, which is still
quite far from 1920x1080.
I don't know if this information is relevant and what it exactly means :
$ xvinfo |grep max
    maximum XvImage size: 1920 x 1080

The i810 driver can benefit from the CacheLines option, by adding this in
xorg.conf : 
Option  "CacheLines"    "1024"

With the following, I can still not play the movie at its native 1920x1080
resolution, but with mplayer scaling it down at 1024x768 , it works.

Apparently, the default for CacheLines is 512, and it can go up to 1040 with an
intel 855 GM chipset.
Comment 9 Xavier 2006-09-11 18:07:36 UTC
Sorry, the maximum CacheLines is in fact 1280.
What I find a bit strange however is that increasing VideoRam (default is 65536)
doesn't seem to help at all. I believe this chipset support up to 128MB, and
that's also what xorg log seems to tell when I try to set VideoRam to a higher
value:

(WW) I810(0): VideoRAM reduced to 196608 kByte (page aligned - was 200000)
(WW) I810(0): VideoRam reduced to 131072 kByte (limited to aperture size)
(II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM
(II) I810(0): BIOS now sees 12288 kB VideoRAM
(--) I810(0): Pre-allocated VideoRAM: 8060 kByte
(**) I810(0): VideoRAM: 131072 kByte
(--) I810(0): Maximum frambuffer space: 130904 kByte

I tried with mplayer again (with VideoRam to either 65536 or 131072) to see what
was the highest 16:9 resolution that didn't crash.
With the default CacheLines (512), it's 1072x603
With CacheLines set to the max (1280), it's 1728x972
Comment 10 Xavier 2006-09-11 18:21:06 UTC
This time, I tried to set the lowest VideoRam, using power of two.
If VideoRam is set to 8192, i810 fails to allocate framebuffer, and xorg can't
start. With VideoRam 16384, it works fine, and I still get the same result with
mplayer than with VideoRam 65536 or 131072.
So VideoRam seems to have 0 influence on this issue, is this expected ?
CacheLines however has a direct influence on it.
Comment 11 Wade Menard 2006-11-08 03:54:17 UTC
I see this on my notebook as well trying to play HD (1280x720) video.

xorg 7.1.1 w/ intel 1.7.2 driver

Intel 945GM w/ 2 GB of RAM

(II) I810(0): detected 7932 kB stolen memory.
(II) I810(0): Kernel reported 488960 total, 1 used
(II) I810(0): I830CheckAvailableMemory: 1955836 kB available
(II) I810(0): Monitoring connected displays enabled
(II) I810(0): Will attempt to tell the BIOS that there is 12288 kB VideoRAM

(II) I810(0): BIOS now sees 12288 kB VideoRAM
(--) I810(0): Pre-allocated VideoRAM: 7932 kByte
(==) I810(0): VideoRAM: 65536 kByte


The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 499 error_code 11 request_code 141 minor_code 19)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Comment 12 Alan Hourihane 2006-11-08 05:01:21 UTC
The original reporter said this was on an ATI chip, but for those running with
Intel chips you need to use the option...

Option "LinearAlloc" "8192"

to give more memory to the allocator to allow for HDTV playback.
Comment 13 Wade Menard 2006-11-08 05:34:30 UTC
Oops. I totally missed that in the man page :embarrassed:

I'm curious, is there a reason the driver cannot allocate this automatically
somehow under various conditions?

Thank you for your help!
Comment 14 Alan Hourihane 2006-11-08 07:50:41 UTC
Normally XAA gets a small portion of memory for offscreen allocation, but due to
rasterizer limits it only gets a smaller portion of memory and it just so
happens that the Xv allocator uses the same memory manager and suffers from the
same restrictions even though the hardware Xv setup doesn't have the limits. 

So, we end up allowing the user to add extra memory resources to the allocator
specifically for Xv. We can define some conditions to allocate more Xv memory,
but it just hasn't been done and so it's left to the user to allocate it.
Comment 15 Colin Brace 2006-11-10 17:16:17 UTC
I'm seeing this as well under Ubuntu 6.10 (xorg 7.1). Sporadically, when I try
to launch the vlc media player, I see this error message:

X Error of failed request:  BadAlloc (insufficient resources for operation)
 Major opcode of failed request:  141 (XVideo)
 Minor opcode of failed request:  19 ()
 Serial number of failed request:  82
 Current serial number in output stream:  83

Rebooting X is the only solution. My video card is:

Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller

I am using the standard i810 xorg driver.


Comment 16 Alan Hourihane 2006-11-10 20:04:40 UTC
Removing me from this bug as the original report is ATI related - not Intel.
Comment 17 Daniel Stone 2007-02-27 01:25:49 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 18 George - 2007-03-12 08:11:34 UTC
Probably a duplicate of bug #474.

To original reporter only:
Please test with a more recent version of Xserver and reopen if it persists. Better yet, open another report as this is swamped by fixed issues on other cards.
Comment 19 Eugenia Loli-Queru 2007-03-15 15:30:00 UTC
The problem PERSISTS with the latest xorg and i810 driver. I had to use the Cachelines trick to make my HD video to work with my Intel 945 card. Otherwise, totem,mplayer,vlc/etc they all crash because Xv can't cope with the large video files.

To test it, just download an HD trailer with an Xv-capable media player.

Please note that for SOME i8xx cards, the Cachelines trick does not work at all, and for those users, they can only hope for a fixed driver.
Comment 20 Marius Andreiana 2007-05-29 22:38:40 UTC
Confirming with xorg-x11-server-Xorg-1.3.0.0-5.fc7 and 
Section "Device"
        Identifier  "Videocard0"
        Driver      "i810"
        Option   "VideoRam"       "65536"
        Option "LinearAlloc" "6144"
EndSection

I get this even with small videos (320x200) if played multiple times with mplayer, which suggest a video memory leak.
Comment 21 Bastien Nocera 2007-07-21 13:56:31 UTC
From bug 10912:
"
After talking to Eric, he mentioned that the problem is because of the use of
XAA. And although he doesn't directly mention what the work-around is, he
repeated it to me during our talk. Add to the device section:
        Option "AccelMethod" "EXA"

It doesn't exactly work well on my machine (performance-wise), but it does play
instead of crashing.
"
Comment 22 Jens Knutson 2007-07-22 21:52:45 UTC
As Hadess says, yes, it works and doesn't crash, but performance is *awful*, and it appears to slow down all other windowing operations in Compiz, too.

For example, changing faces on the cube takes almost a full second if I have any windows up on the new cube face.  Without EXA, it's liquid-smooth, no drag or delay.
Comment 23 Jerome Glisse 2009-05-20 05:25:19 UTC
Closing, EXA acceleration should be a lot better with recent xserver (>1.6.1) and recent x86-video-ati. Reopen if you have same issue with such recent software.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.