Closed Bug 601476 Opened 14 years ago Closed 14 years ago

video playback very slow and 100% cpu usage

Categories

(Core :: Audio/Video, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 581797
mozilla2.0

People

(Reporter: louiz, Unassigned)

References

()

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20101001 Firefox/4.0b7pre
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20101001 Firefox/4.0b7pre

Playing any video (except for very small and very compressed ones) is very slow and takes 100% of the CPU.
Here is a webm example http://www.youtube.com/watch?v=WVTWCPoUt8w&feature=related
and a theora example: http://www.dailymotion.com/html5

Both are displaying approximately 2 frames per second.

My computer is not really a slow one, and I was told that a much older and cheaper hardware could play such video without any trouble.
Moreover, my computer can play any huge video (DVD quality) in ogg or webm with no more than 10 or 20% CPU usage with softwares like mplayer or VLC.

An incompatibility between my hardware and firefox could be the source of the problem.

Reproducible: Always




lspci:

lspci 
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bridge (rev 01)
00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge
00:14.0 CardBus bridge: Texas Instruments PCI4510 PC card Cardbus Controller (rev 02)
00:14.1 FireWire (IEEE 1394): Texas Instruments PCI4510 IEEE-1394 Controller
00:15.0 Network controller: RaLink RT2500 802.11g Cardbus/mini-PCI (rev 01)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
00:19.0 PCI bridge: ALi Corporation M5249 HTT to PCI Bridge
00:1b.0 Ethernet controller: ALi Corporation ULi 1689,1573 integrated ethernet. (rev 50)
00:1c.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
00:1c.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03)
00:1c.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01)
00:1d.0 Multimedia audio controller: ALi Corporation M5455 PCI AC-Link Controller Audio Device (rev 20)
00:1d.1 Modem: ALi Corporation M5457 AC'97 Modem Controller (rev 20)
00:1e.0 ISA bridge: ALi Corporation PCI to LPC Controller (rev 31)
00:1e.1 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
00:1f.0 IDE interface: ALi Corporation M5229 IDE (rev c7)
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon XPRESS 200M 5955 (PCIE)


cat /proc/cpuinfo              
processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 36
model name	: AMD Turion(tm) 64 Mobile Technology ML-32
stepping	: 2
cpu MHz		: 800.000
cache size	: 512 KB
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up rep_good pni lahf_lm
bogomips	: 1600.16
TLB size	: 1024 4K pages
clflush size	: 64
cache_alignment	: 64
address sizes	: 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc
I confirmed high CPU usage of Ogg Video( http://www.dailymotion.com/html5 )playback .

Regression range:
CPU less than 20%:
http://hg.mozilla.org/mozilla-central/rev/6a398023b956
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101002 Firefox/3.7a4pre ID:20100401034504
CPU more then 70%:
http://hg.mozilla.org/mozilla-central/rev/c8f0660250e0
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20101002 Firefox/3.7a4pre ID:20100402030334

And I revert to cgangeset 4613e0369937 in local build then CPU usage less than 20%.
So, The following changeset causes the hight CPU usage in Linux build.

1d00691be5f2	Chris Pearce — Bug 531340 - New Ogg video decoder. r=doublec sr=roc
Blocks: 531340
blocking2.0: --- → ?
Component: General → Video/Audio
Product: Firefox → Core
QA Contact: general → video.audio
Target Milestone: --- → mozilla2.0
Version: unspecified → Trunk
Keywords: regression
We're probably being killed by scaling or YCbCr -> RGB conversion in software on Linux. Those videos play with less than 10% CPU usage under Windows, which will be using Direct3D to do the scaling and colour conversion. Bug 577843 and bug 577843 will help perf on Linux.
(In reply to comment #2)
> Bug 577843 and bug 577843 will help perf on Linux.

Bug 577843 and bug 583138 I mean...
(In reply to comment #2)
> We're probably being killed by scaling
You're right, I just tried to play the video from dailymotion (theora) directly (right clic, copy the video location) on its own page, so without any rescale, and it plays really smoothly.
Same thing with the WebM youtube video. The rescale is killing the performances.

So, yes, it may be a duplicate of bug #577843
Florent, are you using the radeon drivers on Linux?  Do you see the same problem with any other OS?  It's possible you're running into bug 581797.
Actually, if that was the problem you would've seen it in Firefox 3.6 already.
(In reply to comment #5)
> Florent, are you using the radeon drivers on Linux?  Do you see the same
> problem with any other OS?  It's possible you're running into bug 581797.

I am indeed using radeon drivers (on fedora too). And this doesn't happen with an other computer with an Intel video card.
Thank you, I will follow the bug upstream.

(In reply to comment #6)
> Actually, if that was the problem you would've seen it in Firefox 3.6 already.
But it was already slow in Firefox 3.6 (it has always been really slow, AFAIR), it's just that I thought that it was just a lack of optimization and that it would be fixed in latter version. I discovered that other people don't encounter this is…
Since the described symptoms in the other bugs are identical, I would say it's the same bug.
(In reply to comment #7)
> But it was already slow in Firefox 3.6 (it has always been really slow, AFAIR),
Sorry (for the loss of time) if it wasn't clear that this is a pretty old issue, and not a recent regression…
No problem, it's good to have tracked down your problem.  Hopefully this will be fixed before Firefox 4 is released.

I'll mark this as a duplicate of that bug.  It sounds like Alice0775 is seeing a different issue in comment 1, so it'd be best if a new bug was filed with details about that.  Can you please do that, Alice0775?
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
(In reply to comment #9)
> No problem, it's good to have tracked down your problem.  Hopefully this will
> be fixed before Firefox 4 is released.
> 
> I'll mark this as a duplicate of that bug.  It sounds like Alice0775 is seeing
> a different issue in comment 1, so it'd be best if a new bug was filed with
> details about that.  Can you please do that, Alice0775?
> 
> *** This bug has been marked as a duplicate of bug 581797 ***
Filed Bug 601542.
You need to log in before you can comment on or make changes to this bug.