totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver

Bug #111257 reported by mon on 2007-04-30
226
This bug affects 2 people
Affects Status Importance Assigned to Milestone
X.Org X server
Won't Fix
High
Fedora
Fix Released
Medium
compiz (Ubuntu)
Undecided
Unassigned
Nominated for Gutsy by unggnu
xserver-xorg-video-intel (Ubuntu)
High
Michael Vogt
Nominated for Gutsy by unggnu

Bug Description

Hi

I have a widescreen monitor (1440x900) and in order to use it in feisty (x86) I've installed the xserver-xorg-video-intel since 915resolution didn't work out of the box. With this driver I can have maximum resolution and everything seems to work fine, including using video applications (like totem), the problem arises when I'm using compiz and I try to use a video application (totem playing a video or launching pitivi for example).

As said I'm using feisty x86 up to date on a intel x3000 video card.

thanks

Related branches

description: updated
hey560 (hey560) wrote :

I can confirm this bug. It is an XV issue i think.

Changed in totem:
status: Unconfirmed → Confirmed
Niels Breet (maemo) wrote :

I'm having these problems too. Feisty x86 on Intel GMA 3000.

+++ This bug was initially created as a clone of Bug #2772 +++

As mentioned in #2772, this problem persists with the i810 driver.

See also:

http://bugzilla.gnome.org/show_bug.cgi?id=351784

Xorg.0.log, server, and driver version.

John B. (jbuncher) wrote :

I'm having the same issues as well on a 1280x800 screen. For me, switching the video out ("vo") to x11 rather than xv lets the videos play, though I would much rather like to use xv.

1 comments hidden view all 219 comments

gstreamer seems to work with x11 output, but xine doesn't. Since I'm using totem-xine to have dvd playback this isn't a workaround for me.

Baggie (hyperpiper) wrote :

Same here - playing mp3/flac/ video all cause totem to crash when compiz is enabled

Baggie, the crash while playing audio is caused because you have visualizations turned on.

Created an attachment (id=9977)
Xorg.0.log

version:

1.7.4-0ubuntu1

Already fixed.

Eric, which version would that be fixed in?

Same problem here on an intel 915GM, both totem (using gstreamer backend) and mplayer crash receiving the X11 error: "BadAlloc (insufficient resources for operation)"

xf86-video-intel 2.0

I'm using xorg-x11-drv-i810-2.0.0-3.fc7, and still see that problem with compiz running. Running under metacity doesn't show problems.

compiz shouldn't be able to affect this. You're just running compiz on xorg, not compiz on xgl on xorg, right?

No GLX, it's a plain Fedora 7 install. Let me know if you would need to be able to debug this.

wt8008 (wt8008) wrote :

I have the same issue with using the xserver-xorg-video-intel driver in Ubuntu 7.04. Last night I changed drivers and just noticed this issue on my laptop. I have changed back to the xserver-xorg-vide-i810 along and using 915resolution to get 1280x800 on my screen, which is a work around. The reason I tried changing to this driver is because using i810 only gave me two choices for changing resolution in Gnome.

the fix linked by jhasse doesn't work for me on an intel 915GM

wt8008 (wt8008) wrote :

I have an Intel 950GM and the fix also does not work for me.

Doesn't work here.

Intel x3000

Albert Abril (abrilc) wrote :

Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
I'm running the fix 915resolution.

Video only fails when Compiz or Beryl are running, for all the video-players and video-editors.

Doesn't working the fix of jhasse here.

mplayer output:

Starting playback...
VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [xv] 320x240 => 320x240 Planar YV12
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.

Regards.

Same here, xorg-x11-drv-i810-2.0.0-3.fc7, metacity, 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. (totem can't open them anymore too after this occurs)

@Albert

I'm not sure if that is the same bug, if you say you're experiencing
it with 915resolution. The bug that has been reported here (at least
in my case) does NOT involve 915resolution (in fact, that's when stuff
works), but rather with the xserver-xorg-video-intel package/driver,
not the xserver-xorg-video-i810 + 915resolution package/driver/patch
combo.

On 5/29/07, Albert Abril <email address hidden> wrote:
> Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated
> Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
> I'm running the fix 915resolution.
>
> Video only fails when Compiz or Beryl are running, for all the video-
> players and video-editors.
>
> Doesn't working the fix of jhasse here.
>
> mplayer output:
>
> Starting playback...
> VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
> VDec: using Planar YV12 as output csp (no 0)
> Movie-Aspect is undefined - no prescaling applied.
> VO: [xv] 320x240 => 320x240 Planar YV12
> 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.
>
> Regards.
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Albert Abril (abrilc) wrote :

Now, i have the intel driver (without 915resolution), and works fine for my
resolution.
However, with Compiz or Beryl running, still without can't play videos in
any video player.

Now, i can confirm the bug is with the xserver-xorg-video-intel
package/driver.

Thanks for the info.

On 5/30/07, John Buncher <email address hidden> wrote:
>
> @Albert
>
> I'm not sure if that is the same bug, if you say you're experiencing
> it with 915resolution. The bug that has been reported here (at least
> in my case) does NOT involve 915resolution (in fact, that's when stuff
> works), but rather with the xserver-xorg-video-intel package/driver,
> not the xserver-xorg-video-i810 + 915resolution package/driver/patch
> combo.
>
> On 5/29/07, Albert Abril <email address hidden> wrote:
> > Here's the same problem, with a "Intel Corporation 82945G/GZ Integrated
> > Graphics Controller" and a "Flatron TFT L192WS ( 19'' Widescreen )".
> > I'm running the fix 915resolution.
> >
> > Video only fails when Compiz or Beryl are running, for all the video-
> > players and video-editors.
> >
> > Doesn't working the fix of jhasse here.
> >
> > mplayer output:
> >
> > Starting playback...
> > VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12)
> > VDec: using Planar YV12 as output csp (no 0)
> > Movie-Aspect is undefined - no prescaling applied.
> > VO: [xv] 320x240 => 320x240 Planar YV12
> > 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.
> >
> > Regards.
> >
> > --
> > totem crashes with 'BadAlloc (insufficient resources for operation)'
> when
> > using compiz and xserver-xorg-video-intel driver
> > https://bugs.launchpad.net/bugs/111257
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> totem crashes with 'BadAlloc (insufficient resources for operation)' when
> using compiz and xserver-xorg-video-intel driver
> https://bugs.launchpad.net/bugs/111257
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I can confirm this behaviour too; it only happens when compiz is running. It happens with even just a tiny crappy mobile phone video, so it's not related to hd output. If I kill compiz with 'metacity --replace' running the same video then works.

This is with compiz 0.5.0 and the Debian 2.0.0 xserver-xorg-video-intel package on an 915GM/GMS/910GML. I have a very un-fancy xorg.conf with

Section "Device"
        Identifier "Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller"
        Driver "intel"
        BusID "PCI:0:2:0"
        Option "UseFBDev" "true"
        Option "XAANoOffscreenPixmaps" "true"
        Option "DRI" "true"
EndSection

Section "Extensions"
        Option "Composite" "true"
EndSection

Also seems to be reported by ubuntians

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/111257

(In reply to comment #10)
> Option "XAANoOffscreenPixmaps" "true"

Does it happen without this option? (Fedora might still be using the hack to disable XAA offscreen pixmaps when starting a GLX compositing manager)

> Does it happen without this option? (Fedora might still be using the hack to
> disable XAA offscreen pixmaps when starting a GLX compositing manager)

Although I'm using Debian, if I turn this option off none of my terminal window contents get painted, but running "blind" the same thing happens when I try to play a video anyway.

Oh, right. We still have the chance to BadAlloc with XAA, because XAA has no mechanism to force pixmaps into framebuffer. The alternative would be to just violate the composite extension requirements and draw to the front buffer like we used to, but nobody likes that either.

SickNick (sicknick2020) wrote :

I am having the same problem, running on 950GMA from Intel with the 915 driver and 915 resolution fix, it only happens with compiz on. I added the two lines to my xorg and it didnt fix it. Are there any fixes yet on this??

you can try an set a different video sync in gstreamer. I think the command is gstreamer-properties, but I can assure it since Im not at home.

Fine! It worked for me!!

Confirmed: the command is gsreamer-properties.

I went to the video tab, I selected "Default Output -> Plugin: X Window
System ( No XV )," and now works fine with Totem.
Only for totem. Not for mplayer neither VLC. Then, is reconfirmed that the
point is in the video output selected.

Thanks.

On 6/15/07, kmon <email address hidden> wrote:
>
> you can try an set a different video sync in gstreamer. I think the
> command is gstreamer-properties, but I can assure it since Im not at
> home.
>
>

Hi

It only works for gstreamer based player (so it doesn't work with totem-xine either).

I've experienced this problem too, in my normal x-session with beryl+kde all attempts to use Xv fails with the BadAlloc error message.
I've tested to comment out all Options to the intel driver in my xorg.conf, and starting the X server with only an xterm in it, then Xv playback works. If i start beryl it breaks, when i kill beryl it works again. The same goes for xcompmgr.

I've tested with both xserver-xorg-video-intel version 2.0.0-1ubuntu2 and a git snapshot from 2007-06-18 with the same results.

Changed in xorg-server:
status: Unknown → Confirmed

Confirmed on an archlinux system using xorg-server 1.3, the intel 2.0.0 driver, kde 3.5.7 and any player with Xv output. Opengl and other output works fine.

Jeffrey Knockel (jeff250) wrote :

Setting the video output plugin to "X Window System ( No XV )" means that you won't be getting xv video acceleration. This puts more strain on the CPU during video playback, and higher resolution videos can play jerkily.

Changed in compiz:
status: Confirmed → Invalid
Changed in xserver-xorg-video-intel:
status: New → Confirmed
Changed in xserver-xorg-video-intel:
importance: Undecided → High
Michael Vogt (mvo) on 2007-09-13
Changed in compiz:
status: Invalid → Confirmed
Michael Vogt (mvo) on 2007-09-18
Changed in compiz:
status: Confirmed → Fix Released
Michael Vogt (mvo) on 2007-09-19
Changed in xserver-xorg-video-intel:
assignee: nobody → mvo
status: Confirmed → Fix Released
139 comments hidden view all 219 comments

Note that it affects other video apps too -- gxine and vlc.

On Thinkpad T61, Intel X3000, with Rawhide x86_64 installed:

Subjectively, turning on EXA seems to slow down scrolling in Firefox a bit, but
glxgears shows the same level of performance, so it might just be me. But it
does let me use compositing and Xv at the same time (i.e. watching videos under
Compiz).

Without EXA, even playing a sound file would crash Totem with the default
settings (visualization is turned on by default).

Should system-config-display automatically turn on EXA for some whitelisted list
of system configurations?

Correction -- video performance *is* still terrible.

*** Bug 237169 has been marked as a duplicate of this bug. ***

Can F8 users test the latest tree with XAA video should at least play..

(In reply to comment #32)
> Can F8 users test the latest tree with XAA video should at least play..

Works using xorg-x11-drv-i810-2.1.1-7.fc8, but it's just about as slow as using EXA.

Created attachment 279371
Compiz + VLC = lag and bad video

maybe it's a compiz problem?

Changed in xorg-server:
status: Confirmed → Won't Fix

Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

*** Bug 440262 has been marked as a duplicate of this bug. ***

I can confirm that this still happens with F9 rawhide latest with these packages:

kernel-2.6.25-0.185.rc7.git6.fc9.x86_64
xorg-x11-drv-i810-2.2.1-19.fc9.x86_64
xorg-x11-server-common-1.4.99.901-16.20080401.fc9.x86_64
xorg-x11-server-Xorg-1.4.99.901-16.20080401.fc9.x86_64

I have this problem even without compiz on a ThinkPad T61 with Intel GM965 chip.

(In reply to comment #36)
> *** Bug 440262 has been marked as a duplicate of this bug. ***

Ok, it appears now Xv is not working not only with Compiz which is my case
#440262.

But the difference is that I didn't have such problems with Xorg from
December 2007/January 2008:

xorg-x11-server-Xorg-1.3.0.0-39.fc8.i386
xorg-x11-drv-i810-2.1.1-7.fc8.i386

In fact Xv was working great with "intel" driver even with high definition
video files with 1920x1080 resolution.
At this point the new Xorg 1.4 appeared in rawhide.
My latest check with newer drivers was around February, but can't find
exact version as of this time. The problem then was that with EXA which was
chosen as default is very slow. Changing to XAA resulted to distorted fonts
in terminals but the video was playable with Xv. Then I switched back to older
version.
As of one-two weeks ago I changed Xorg to the latest in rawhide again and
noticed the problem which I've reported here as bug #440262.
The problem is somewhere in the updates from the last 1-2 months, not as
with #239125 a year ago.

*** Bug 438361 has been marked as a duplicate of this bug. ***

*** Bug 441647 has been marked as a duplicate of this bug. ***

Seeing the same here with latest rawhide and
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

X11 is the only option to play anything. No compiz, same with compositing
enabled and disabled in metacity.

*** Bug 441777 has been marked as a duplicate of this bug. ***

Directed here as my bug was marked as a duplicate. In my case I'm using
metacity and the problem has appeared in the past week or so.

Same here on a Fujitsu Lifebook using mplayer. It spits out endless
BadAlloc errors and nothing appears in the video output.

This is with metacity.

Intel Corporation Mobile 915GM/GMS/910GML (rev 04)

xorg.conf is using driver "intel"

It would be nice to hear that some Xorg developer has tried to use xv
with the current packages in fedora rawhide, and either had success or
can reproduce the problem.

The fun thing is, this used to work up to the last two weeks or so (on a 945GM,
intel driver). Now it does not, and I have not found out what package caused the
breakage.

Xine, for example, works fine with Xv. vlc does not.

Building and installing the latest driver posted by intel:

http://lists.freedesktop.org/archives/xorg/2008-April/034668.html

Makes the problem go away completely for me.

I can't believe I'm the first person, either as bug reporter or
owner, to try this.

Hi, I am having this issue as well. Here's my testing for normal-res and low-res
video in totem-gstreamer, gxine, xine, mplayer and vlc, with plain metacity,
with compositing manager enabled in metacity, I'll attach Xorg.0.log and xorg.conf.

plain metacity:

programme 720x384, 23.976 fps 320x239, 30.000 fps
totem-gstreamer plays, but displays error plays
gxine SEGFAULTs SEGFAULTs
xine SEGFAULTs plays
mplayer only audio only audio
vlc crash -

Displayed errors/warnings on cosole:
totem:
No accelerated IMDCT transform found

mplayer:
X11 error: BadAlloc (insufficient resources for operation)

vlc:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 86
  Current serial number in output stream: 87
Segmentation fault

Metacity with compositing:
nothing works, showed errors:
Totem:
The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.

mplayer:
X11 error: BadAlloc (insufficient resources for operation)

vlc:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 86
  Current serial number in output stream: 87
Segmentation fault

xine:
X Error of failed request: BadAlloc (insufficient resources for operation)
  Major opcode of failed request: 140 (XVideo)
  Minor opcode of failed request: 19 ()
  Serial number of failed request: 2342
  Current serial number in output stream: 2343

x11 and gl2 video output drivers work (slow, and with compositing enabled gl2
also with rendering issues) both with and without compositing.

I've noticed this bug on upstream bugzilla which seems to be similar:
https://bugs.freedesktop.org/show_bug.cgi?id=2772

I'll try the latest driver (as suggested by davem) to see if it's better and
report the results.

Created attachment 302372
My Xorg.0.log when testing in totem, gxine, xine, vlc and mplayer

Created attachment 302373
my xorg.conf

There is one option added in the xorg.conf manualy which was suggested on
test-list as possible fix (with no luck).

Oh, and I forgot the package versions...

xorg-x11-server-Xorg-1.4.99.901-21.20080407.fc9.i386
xorg-x11-drv-i810-2.2.1-20.fc9.i386

(In reply to comment #46)

> I can't believe I'm the first person, either as bug reporter or
> owner, to try this.

I can't get this to build, configure craps out on me saying
./configure: line 20451: syntax error near unexpected token `XINERAMA,'
./configure: line 20451: `XORG_DRIVER_CHECK_EXT(XINERAMA, xineramaproto)'

Naked driver, btw, no patches ported from the rawhide driver, following the
.spec instructions manually.

I wouldn't worry about upstream vs. RH build, this is almost certainly just
using EXA vs XAA. (check your logs.)

I've just rebased rawhide rpm to the new version and it builds OK (but I need to
update the %%file section). I'll post a srpm when it's done.

Ok, as promised, here's the SPRM:

http://mso.fedorapeople.org/rawhide/xorg-x11-drv-i810-2.2.99.903-0.1.fc9.src.rpm

The changes are: removed patch 6,7 and 10 (seems they were just backports from
git), edited patch 5, added libIntelXvMC.so* libs.

I have yet to test, whether it works...

My config is using EXA.

The update to 2.2.99.903 didn't solved the problem, but I noticed that XAA was
used. So I switched to EXA, which makes videos playable in mplayer with -vo xv
again, but HD (720p) is being quickly desynced with sound (and enabling
framedropping does not help)...

This is still broken in the default Fedora-9-Preview install, and adding:

      Option "AccelMethod" "EXA"

to xorg.conf fixes it.

Please test xorg-x11-drv-i810-2.2.1-21.fc9, available at:
  http://koji.fedoraproject.org/packages/xorg-x11-drv-i810/2.2.1/21.fc9/

and in tomorrow's rawhide.

I'll note that this build fixes it for me.

2.2.1-21.fc9 fixes Xv for me.

BTW, I'm still having this exact same problem with radeon. Does the same fix to
i810 apply to radeon?

Not that I know of. You can always try frobbing the config option, of course.

xorg-x11-drv-i810-2.2.1-22.fc9 also contains a fix for the XAA case, so overlay
video should work no matter what now (although obviously it won't blend
correctly when compositing).

Tested on i865, closing.

Download full text (4.1 KiB)

Hi,
I have some high-def video trailers I downloaded via azureus and I
can't play them on F9 Preview (with all codecs installed).

I have been running Rawhide for some time now and when I saw this bug
I thought it could be something I did so I did a clean install of F9
Preview and installed fluendo codecs for totem, and also installed vlc
and mplayer (with codecs) from livna.

None player can play these mkv files that I can play without any
problems under Fedora 8 with all of mentioned video players.

I have Intel graphic chip:
Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated
Graphics Controller (rev 03)

To reproduce this bug do this:
1. yum install azureus
2. start azureus
3. download some high-def video trailer (Iron Man for example)
4. install video player + codecs (vlc, mplayer, totem + fluendo codecs
- take your pick)
5. play high-def video

I get these errors:

$ totem IronManTrailer2-1080p.mkv
** Message: Error: File
"/usr/lib/gstreamer-0.10/libmch264dec.so.7.4.0.20778" could not be
used.
fluh264dec.c(414): gst_fluh264dec_setup (): /play/decodebin0/fluh264dec0:
Could not open module: libstdc++.so.5: cannot open shared object file:
No such file or directory

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

(totem:9953): GStreamer-CRITICAL **: gst_object_unref: assertion
`object != NULL' failed

$ mplayer IronManTrailer2-1080p.mkv
MPlayer SVN-r25979 rpm.livna.org (C) 2000-2007 MPlayer Team
CPU: Intel(R) Core(TM) Duo CPU T2450 @ 2.00GHz (Family: 6,
Model: 14, Stepping: 12)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
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 IronManTrailer2-1080p.mkv.
[mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0
[mkv] Track ID 2: audio (A_VORBIS), -aid 0, -alang und
[mkv] Will play video track 1.
Matroska file format detected.
VIDEO: [avc1] 1920x816 24bpp 23.952 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
==========================================================================
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 48000 Hz, 2 ch, s16le, 0.0 kbit/0.00% (ratio: 0->192000)
Selected audio codec: [ffvorbis] afm: ffmpeg (FFmpeg Vorbis decoder)
==========================================================================
AO: [alsa] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 1920 x 816 (preferred colorspace: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 2.35:1 - prescaling to correct movie aspect.
VO: [xv] 1920x816 => 1920x816 Planar YV12
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warning: No suitable new res found!
[ASPECT] Warni...

Read more...

I just added this to my xorg.conf:

Option "AccelMethod" "EXA"

I'll report how it works now after reboot or X restart.

Bug 445395 may be related.

Changed in xorg-server:
importance: Unknown → High
Changed in xorg-server:
importance: High → Unknown
Changed in xorg-server:
importance: Unknown → High
Changed in fedora:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 219 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.