GNOME Bugzilla – Bug 112750
X Error of failed request: BadAlloc (insufficient resources for operation)
Last modified: 2004-12-22 21:47:04 UTC
gst-launch videotestsrc width=512 height=513 ! xvideosink INFO (16418: 0) Initializing GStreamer Core Library version 0.7.0.1 INFO (16418: 0) Adding plugin path: "/home/ds/gst/gstreamer/" INFO (16418: 0) Adding plugin path: "/home/ds/gst/gst-plugins/" INFO (16418: 0) CPU features: (0c040841) MMX error Error on line 11904 char 59: Invalid UTF-8 encoded text ERROR: parsing registry: Error on line 11904 char 59: Invalid UTF-8 encoded text INFO (16418: 0) registry: loaded global_registry in 0.049684 seconds (/home/ds/gst/gstreamer/registry.xml) setting pattern to 0 RUNNING pipeline videotestsrc: using fourcc element 0x400762e0 YUY2 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: 27 Current serial number in output stream: 28 Anything over ~262144 pixels (i.e., 512x512) causes this error on my machine. This feels like potentially a bug in X, since the xvinfo output seems to indicate that the maximum size is 1024x1024. output of xvinfo: X-Video Extension version 2.2 screen #0 Adaptor #0: "NeoMagic Video Engine" number of ports: 1 port base: 55 operations supported: PutVideo PutImage supported visuals: depth 16, visualID 0x23 depth 16, visualID 0x24 number of attributes: 3 "XV_COLORKEY" (range 0 to 16777215) client settable attribute client gettable attribute (current value is 2110) "XV_BRIGHTNESS" (range -128 to 127) client settable attribute client gettable attribute (current value is 0) "XV_INTERLACE" (range 0 to 2) client settable attribute client gettable attribute (current value is 0) number of encodings: 1 encoding ID #0: "XV_VIDEO" size: 1024 x 1024 rate: 1.000000 maximum XvImage size: 1024 x 1024 Number of image formats: 5 id: 0x32595559 (YUY2) guid: 59555932-0000-0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (YV12) guid: 59563132-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (I420) guid: 49343230-0000-0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x35315652 (RV15) guid: 52563135-0035-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x3e0, 0x7c00 id: 0x36315652 (RV16) guid: 52563136-0000-0000-0000-000000000000 bits per pixel: 16 number of planes: 1 type: RGB (packed) depth: 0 red, green, blue masks: 0x1f, 0x7e0, 0xf800
According to people in #xwin, this may or may not be an X bug, but gstreamer should recover in any case. The problem is likely to do lack of video ram for a larger XV overlay. The XV protocol is not capable of specifying the largest allocation, so if we care, we need to probe for an available size, which is gross. In addition, xvideosink should pay attention to the max height/width parameters, and provide those in the caps.
Added a check to make sure that XvShmPutImage succeeds before going to READY. So now we get a gst_element_error() and a graceful ending instead of an abort.