Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 516494 - Playing video causes extremely high CPU usage
Summary: Playing video causes extremely high CPU usage
Keywords:
Status: CLOSED DUPLICATE of bug 502913
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 11
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Adam Jackson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-10 08:28 UTC by Cesko Voeten
Modified: 2018-04-11 11:58 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-10-08 16:51:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg.0.log (deleted)
2009-10-07 16:44 UTC, Cesko Voeten
no flags Details

Description Cesko Voeten 2009-08-10 08:28:31 UTC
Note: I reported this bug against Totem, but ALL other media players I tried (VLC and Mplayer) have the same problem. I do not know which common component is causing the issues, therefore I chose to report it against the player (Totem) itself. I apologize if I did this in error.

Description of problem:
Playing any video file causes the player process to consume around 80% cpu (around 150% according to top). (3ghz dual core intel processor).
Audio-only files play fine.

The videocard I'm using is an Intel 865g, and I'm using KMS. (Not sure whether this is relevant - unfortunately X crashes whenever I try to log in with KMS disabled, so I can't check whether KMS is causing this)

Version-Release number of selected component (if applicable):
totem: 2.26.3
xorg-x11-drv-intel (not sure whether relevant): 2.7.0-7.fc11

uname -a output:
Linux [removed computer name] 2.6.29.6-217.2.3.fc11.i686.PAE #1 SMP Wed Jul 29 16:05:22 EDT 2009 i686 i686 i386 GNU/Linux

How reproducible:
Always.

Steps to Reproduce:
1.launch the 'top' program in a terminal (so that you can observe the CPU usage)
2.play a video file in any media player
3.observe the CPU usage of the player process rise to an extremely high level
  
Actual results:
CPU usage is very high, video plays choppy

Expected results:
CPU usage is 'reasonable' (on Windows, using VLC, the CPU usage never goes above ~10%)

Additional info:
Videocard: intel 865G
KMS enabled
Tried various configurations of affected programs (VLC/Totem/Mplayer) to no avail

Comment 1 Bastien Nocera 2009-10-05 12:20:53 UTC
My guess is that there's no Xv acceleration on your system.

What's the output of "xvinfo" on your system? Is it only certain file types or a certain file that causes problems?

Comment 2 Cesko Voeten 2009-10-06 13:56:24 UTC
xvinfo output:

X-Video Extension version 2.2
screen #0
 no adaptors present

(strange.... is this a driver issue?)

I tried a few files (mostly avi but also mpg and wmv), and they were all affected.

Comment 3 Bastien Nocera 2009-10-06 16:39:38 UTC
This is definitely a driver issue, or a configuration issue. Your video is completely unaccelerated.

Attach /var/log/Xorg.0.log and /etc/X11/xorg.conf to this bug.

FYI, this is what it looks like on a working card:

X-Video Extension version 2.2
screen #0
  Adaptor #0: "Intel(R) Textured Video"
    number of ports: 16
    port base: 71
    operations supported: PutImage 
    supported visuals:
      depth 24, visualID 0x21
[...]

Comment 4 Cesko Voeten 2009-10-07 16:44:03 UTC
Created attachment 364001 [details]
Xorg.0.log

Comment 5 Cesko Voeten 2009-10-08 06:11:33 UTC
xorg.conf didn't exist (sorry for not mentioning this in my previous comment, I *thought* I had mentioned it in that comment but I now see I didn't)

Comment 6 Matěj Cepl 2009-10-08 16:51:21 UTC

*** This bug has been marked as a duplicate of bug 502913 ***


Note You need to log in before you can comment on or make changes to this bug.