MPlayer receives BadAlloc when playing very large movies using Xv

[Munzir Taha (منذر طه)]

Playing files at www.monoppix.com/tutorials/ crash mplayer. Rathann at #mplayer confirmed that this doesn't happen with the latest version but he mentioned that -vc ffwmv2 may be required

munzir@ubuntu:~/Desktop$ mplayer monoforwindows.wmv
MPlayer 2:0.99+1.0pre7try2+cvs20060117-0ubuntu6 (C) 2000-2006 MPlayer Team
CPU: Intel Pentium M Dothan (Family: 6, Stepping: 6)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

91 audio & 204 video codecs
Failed to open /dev/rtc: No such file or directory (it should be readable by the user.)
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.
Playing monoforwindows.wmv.
ASF file format detected.
VIDEO: [WMV2] 1024x768 24bpp 1000.000 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8003->176400)
Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))
==========================================================================
==========================================================================
Opening video decoder: [dshow] DirectShow video codecs
Decoder supports the following YUV formats: YUY2 IYUV UYVY YV12 YVYU I420 YVU9
Decoder is capable of YUV output (flags 0x7f)
VDec: vo config request - 1024 x 768 (preferred colorspace: Packed YUY2)
[PP] Using codec's postprocessing, max q = 4.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 1024x768 => 1024x768 Planar YV12
Selected video codec: [wmv8] vfm: dshow (Windows Media Video 8)
==========================================================================
Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
alsa-init: 1 soundcard found, using: default
alsa: 44100 Hz/2 channels/4 bpf/60208 bytes buffer/Signed 16 bit Little Endian
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
Starting playback...
X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0

MPlayer interrupted by signal 6 in module: vo_check_events
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.
alsa-uninit: pcm closed

[Antoszka (antoszka)]

Created an attachment (id=2149)
My xorg.conf

[Antoszka (antoszka)]

Created an attachment (id=2150)
Output from xvinfo

[Antoszka (antoszka)]

Created an attachment (id=2151)
My current Xorg.0.log

[Antoszka (antoszka)]

Created an attachment (id=2152)
Out from emerge --info on my Gentoo system.

This file might include some useful information for anybody reviewing this bug.

[Antoszka (antoszka)]

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.

[Devnull-freedesktop (devnull-freedesktop)]

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.

[Vda (vda)]

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 <email address hidden> 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 <email address hidden>
+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).

[Munzir Taha (منذر طه) (munzirtaha)]

Playing files at www.monoppix.com/tutorials/ crash mplayer. Rathann at #mplayer confirmed that this doesn't happen with the latest version but he mentioned that -vc ffwmv2 may be required

munzir@ubuntu:~/Desktop$ mplayer monoforwindows.wmv
MPlayer 2:0.99+1.0pre7try2+cvs20060117-0ubuntu6 (C) 2000-2006 MPlayer Team
CPU: Intel Pentium M Dothan (Family: 6, Stepping: 6)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.

91 audio & 204 video codecs
Failed to open /dev/rtc: No such file or directory (it should be readable by the user.)
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support.
You will not be able to use your remote control.
Playing monoforwindows.wmv.
ASF file format detected.
VIDEO: [WMV2] 1024x768 24bpp 1000.000 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 64.0 kbit/4.54% (ratio: 8003->176400)
Selected audio codec: [ffwmav2] afm: ffmpeg (DivX audio v2 (FFmpeg))
==========================================================================
==========================================================================
Opening video decoder: [dshow] DirectShow video codecs
Decoder supports the following YUV formats: YUY2 IYUV UYVY YV12 YVYU I420 YVU9
Decoder is capable of YUV output (flags 0x7f)
VDec: vo config request - 1024 x 768 (preferred colorspace: Packed YUY2)
[PP] Using codec's postprocessing, max q = 4.
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 1024x768 => 1024x768 Planar YV12
Selected video codec: [wmv8] vfm: dshow (Windows Media Video 8)
==========================================================================
Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
alsa-init: 1 soundcard found, using: default
alsa: 44100 Hz/2 channels/4 bpf/60208 bytes buffer/Signed 16 bit Little Endian
AO: [alsa] 44100Hz 2ch s16le (2 bytes per sample)
Building audio filter chain for 44100Hz/2ch/s16le -> 44100Hz/2ch/s16le...
Starting playback...
X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0

MPlayer interrupted by signal 6 in module: vo_check_events
- MPlayer crashed. This shouldn't happen.
  It can be a bug in the MPlayer code _or_ in your drivers _or_ in your
  gcc version. If you think it's MPlayer's fault, please read
  DOCS/HTML/en/bugreports.html and follow the instructions there. We can't and
  won't help unless you provide this information when reporting a possible bug.
alsa-uninit: pcm closed

[Paul Sladen (sladen)]

The BadAlloc because mplayer is requesting more resources than the video card can provide. In this case, it doesn't have enough spare RAM on the video card to allocate 1024x768 Xvideo buffers.

Another time this happens is if a decode size is requested that is larger than the hardware can cope with.

[Blue (vali-dragnuta)]

I can confirm this bug. It happens with totem AND mplayer, but it's a xorg bug. This stupid bug keeps reappearing in al xorgs, while I never had this with xfree. The problem is that xorg is not smart enough to allocate memory required for xv framebuffers.

BTW : one of agp's design goals was to allow the graphic subsystem to use system's memory for graphics purposes, thing that xorg obviously does not, while xfree DID.

[Xavier (chantry-xavier)]

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.

[Xavier (chantry-xavier)]

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

[Xavier (chantry-xavier)]

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.

[Xavier (chantry-xavier)]

It seems like it has been reported upstream :
https://bugs.freedesktop.org/show_bug.cgi?id=2772

I think I also saw a previous report on ubuntu launchpad, but can't find it again.

[Wade Menard (wade-ezri)]

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.)

[Alanh-fairlite (alanh-fairlite)]

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.

[Wade Menard (wade-ezri)]

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!

[Alanh-fairlite (alanh-fairlite)]

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.

[Colin Brace (cbrace)]

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.

[Alanh-fairlite (alanh-fairlite)]

Removing me from this bug as the original report is ATI related - not Intel.

[Matthew East (mdke)]

Moving to xorg then. I also have this bug, even on a video of about 20MB.

[Florian Boucault (fboucault)]

Bug #49360 is more or less the same as well as #39050.

[Daniel Stone (daniels)]

Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.

[Giorgos Sapountzis (fufutos610)]

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.

[Eugenia Loli-Queru (eloli)]

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.

[PhaseR (bidea-cristian)]

I tried to solve this by using -vo gl option and it worked! (mplayer -vo gl)

My video card is
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA])
        Subsystem: Gateway 2000 Unknown device 0685
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 17
        Region 0: Memory at d8100000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at 1800 [size=8]
        Region 2: Memory at c0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at d8200000 (32-bit, non-prefetchable) [size=256K]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0 Enable-
                Address: 00000000 Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

[Bartek (tschew)]

Another solution is to set the "LinearAlloc" option in xorg.conf for the i810 driver to something very big. If you check "man i810" it gives 8160 as a value for 1080p videos, i find that it is insufficient, crashing even with 720p videos. At 16000 I haven't had any problems yet.

....
Section "Device"
        Identifier "Intel Corporation Mobile 915GM/GMS/910GML Express Grap
        Driver "i810"
        Option "LinearAlloc" "16000" #STOP CRASHING XVIDEO
        BusID "PCI:0:2:0"
EndSection
.....

[MA (mariusa)]

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.

[Bastien Nocera (hadess-deactivatedaccount)]

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.
"

[Jens-knutson (jens-knutson)]

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.

[Bryce Harrington (bryce)]

Can you test if switching from the i810 driver to the intel driver makes this issue go away? If so, then the fix for bug 135141 will fix this one as well.

[Xavier (chantry-xavier)]

I'm no longer using Ubuntu, but I can confirm this makes the problem go away.
I am currently using the intel driver (2.1.1) without any particular settings in xorg.conf ,
and the Elephants Dream movie now works fine ( https://bugs.freedesktop.org/show_bug.cgi?id=2772#c7 ).
I switched back to i810 (1.7.4), and it crashes again, just like before.
I suppose this applies to Ubuntu as well.

[Munzir Taha (منذر طه) (munzirtaha)]

I am still using Ubuntu Feisty Fawn with
xserver-xorg-video-intel 1.9.94-1ubuntu4
and the problem is still there

[Lethe (nick-ukfsn)]

OK, I have this error with cube etc. turned on (7.04 Dell pre-installed Inspiron 6400).

X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0

But I found a google thread that says this:

Try:

> mplayer -vo x11 foo.avi

This works for me!!!

Nick

[Bryce Harrington (bryce)]

It's been a while since there was any comment here or upstream for this bug. Is anyone still seeing this problem?

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

[Glisse (glisse)]

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.

[Marcerino (mastervanleeuwen)]

This issue is still/again present in Jaunty Jackalope. The problem occurs with totem-gstreamer, but also with VLC player and mplayer. This can be circumvented by not using Xvideo (all players have options for this), e.g. use:

mplayer -vo gl
mplayer -vo x11

(as suggested in Bug 493360)

Here is the relevant section of the XOrg.log file:
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): Using hsync ranges from config file
(II) intel(0): Using vrefresh ranges from config file
(II) intel(0): Printing DDC gathered Modelines:
(II) intel(0): Modeline "1280x800"x0.0 69.30 1280 1328 1360 1419 800 803 809 816 -hsync -vsync (48.8 kHz)
(II) intel(0): EDID vendor "SEC", prod id 21569
(II) intel(0): xf86BindGARTMemory: bind key 2 at 0x07330000 (pgoffset 29488)
(II) intel(0): xf86UnbindGARTMemory: unbind key 2
(EE) intel(0): Failed to pin xv buffer
(EE) intel(0): Failed to pin xv buffer
(EE) intel(0): Failed to pin xv buffer

[Munzir Taha (منذر طه) (munzirtaha)]

Yes, I am the original reporter and the bug is still valid for the same mono video I tried before. I tested now with latest karmic snapshot.

[Bryce Harrington (bryce)]

Munzir, please attach an Xorg.0.log from after re-testing this issue. I would also encourage you to re-open the upstream bug so they can investigate. https://bugs.freedesktop.org/show_bug.cgi?id=2772

[Munzir Taha (منذر طه) (munzirtaha)]

Bryce, I am sorry for the inaccurate comment. I consider this bug fixed now. I am facing another issue which shouldn't be confused with this bug.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

Hi Munzir,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 38939

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 38939 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/38939

[rusivi2 (rusivi2-deactivatedaccount)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. My apologies as I should not have marked this Invalid. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Maverick Meerkat. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Munzir Taha (منذر طه) (munzirtaha)]

I reported this bug more than 4 years ago and during this time I changed my platform/laptop 70 times. I have removed those mono video tutorials when Richard Stallman stated it may be "dangerous" to use Mono because of the possible threat of Microsoft patents. I really appreicate your hard work but dealing with bugs should be faster than this.

In summary, close this bug as "Fixed" since the upstream claims so and if you have any time please help me resolve Bug #642230 before I sell this laptop, too ;)

[Timo Aaltonen (tjaalton)]

ok, closing as per request.