User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081101 Firefox/2.0.0.11 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081101 Minefield/3.1b2pre ID:20081101032525 Firefox's OGG video playback is extremely inefficient (very slow and choppy) and consumes 100 % CPU regardless of the video. For example, the video at http://upload.wikimedia.org/wikipedia/commons/2/23/Moving_Octopus_Vulgaris_2005-01-14.ogg is played with 100 % CPU compared to 38 % with VLC Player Similarly, the video here: http://lachy.id.au/dev/markup/tests/html5/video/003.html, though very simple, plays with 100 % CPU and very choppy audio Even though my system is a P3 933 MHz (GenuineIntel family 6 model 8 stepping 6), it is not the problem, as VLC Player achieves smooth playback with about a third of the CPU power that Firefox demands for its slow and choppy playback. Reproducible: Always Steps to Reproduce: Steps to Reproduce: 1. Open Windows Task Manager 2. Visit the linked URL 3. Start video playback 4. Monitor CPU utilization Actual Results: 100 % CPU utilization, choppy video, choppy audio with the second specified URL Actual Results: First video show play smoothly with only about a third of the CPU utilization, much like VLC Player.

Addressing bug 462163 comment 6, yes the stop/start is buffering. Events are raised when this occurs but the UI doesn't pick up on it to display anything yet. Custom built Javascript UI's can however. It's possible recent video changes on trunk have affected Windows performance - I'll look into it. One point though, you will not see as good performance as that of VLC if VLC is using hardware features of your video card (like overlays). This is because we cannot do hardware display of the video data using features of the video card. We have to get the decoded bits and send them through the HTML rendering pipeline so that overlay of other HTML elements, CSS styling, etc can affect the video. That said there is room for performance increases, especially on Windows, and we are looking into them.

dupe of bug 449175?

Note a dupe. That bug is for a case where 100 % CPU occurs at the mere presence of the <video> tag and has nothing to do with actual video playback.

I'd just like to add, on WindowsXP, I get quite choppy <audio> playback performance, as well as choppy <video> playback. Unusable as it is currently. What I have found however, is that opening another tab and selecting that, eases the choppiness massively. Similarly, minimizing Firefox to the taskbar will also improve playback performance. If this observation is *not* related to the bug ticket in question, my apologies, and please delete this if required. I'll raise a separate ticket in such case.

Bug 470639 also made that point and I've observed the same. Related bugs for fixing performance issues like this are: Bug 474748 Bug 474479 Bug 474540

That second one should be Bug 474749. I'm not suggesting replace your windows box with a mac mini :)

(In reply to comment #7) > That second one should be Bug 474749. I'm not suggesting replace your windows > box with a mac mini :) ha ha, not a bad tip though :-) One last thing I forgot to point out, under similar circumstances (same <audio> element using webpage), linux (ubuntu latest) is unaffected by screen drawing and is mostly quite reliable. Looking at the tickets you point out, you appear to have targeted platform specificity as an area of improvement, but I thought I should share the experience in Linux anyway.

(In reply to comment #5) > I'd just like to add, on WindowsXP, I get quite choppy <audio> playback > performance, as well as choppy <video> playback. Unusable as it is currently. > What I have found however, is that opening another tab and selecting that, > eases the choppiness massively. Similarly, minimizing Firefox to the taskbar > will also improve playback performance. > > If this observation is *not* related to the bug ticket in question, my > apologies, and please delete this if required. I'll raise a separate ticket in > such case. The "choppy" video and audio repros pretty commonly on a mac PPC machine all the time. Tested against Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3. Using the test clip from http://tinyvid.tv/show/3uwvr4t3wi3rm Should we relnote this for beta 3? It affects mac PPC's for sure, but i can't reproduce this on windows XP as comment 5 says

It is highly dependant on the speed of the machine. Slower machines will have choppy audio/video.

(In reply to comment #10) > It is highly dependant on the speed of the machine. Slower machines will have > choppy audio/video. Ran on two different machines, and both still show the "choppiness": - 1.5 Ghz PPC G4, 512 Mb DDR SDRAM, OSX 10.5.3 - Dual 1.8 Ghz, PPC G5, 1.25 GB SDRAM, OSX 10.5.6 If its speed dependent, at what point do we "support" video on older machines?

I will add, that I've been testing <audio> performance on a dual booting AMD Athlon, 1.8Ghz machine with 1GB of RAM. Booting Ubuntu latest and Windows XP. In Ubuntu, the performance is great, with no choppiness (memory usage is another matter), but in WindowsXP, I rarely get a faultless stream, with interruptions caused by any Disk I/O activity, any screen drawing. Testing the above link (http://tinyvid.tv/show/3uwvr4t3wi3rm ) on this machine, I get similar choppiness as described earlier. I haven't been working with <video> much in my own project, only <audio>, but testing the link, it's the same issues. I can try and do the same testing on OSX, but I'd have to do that at work.

I can't mark this 'wanted' because it's not specific enough. John-Paul's comments sound to me like the audio buffer on Windows XP is not big enough, which if true would be a separate bug.

(In reply to comment #11) > If its speed dependent, at what point do we "support" video on older machines? "older machines" of course considers only CPU performance, but what if someone has an HD capable graphics processor? For example this same P3 933 system that is struggling with Firefox's OGG media support can handily play 1080p HD video with only about 30 % CPU utilization, because I have a Radeon HD 2400Pro graphics adapter.

related to support, and a minimum spec, what are the plans for media tag inclusion on Fennec? I assume the performance would have to be top notch for platforms where hardware resource is a premium.

In Firefox 3.1 beta 3, playing ogg theora via <video> is choppy and audio lags nearly a half second behind, for both online content and local content at reasonable bitrates. CPU at 100% Tested on AMDAthlon 64 3500 2.2GHz with 2GB ram, Windows XP. Upon pausing the video, it cannot resume, but shows loading icon spinning in middle of darkened video --cannot recover from this. CPU usage drops to 50% at this point.

The bug is still there - 3.1 beta 3, high-end machine, Windows XP - 100% of a CPU core on <video> play (any OGG video, any resolution).

(In reply to comment #17) > The bug is still there - 3.1 beta 3, high-end machine, Windows XP - 100% of a > CPU core on <video> play (any OGG video, any resolution). Please use the latest development builds available when commenting/testing bugs. You can find 3.5 builds at ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-1.9.1/ and latest-trunk (3.next) at ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/ .

This bug is still present in Firefox 3.5 Beta 4, on a machine running Windows XP with 1.5 GB RAM and a 2.9 GHz processor.

Has this gotten better enough now that I can remove this relnote? I haven't been running into any problems ...

Firefox 3.5.b99, WinXP, 32-bit: apparently fixed for some videos, not for others. It looks like it's directly related to video canvas size - small videos (e.g. 640x480) play with 20-50% CPU usage (which is still HUGE, compared to standalone players), while videos that are stretched to the whole browser window eat 100% CPU, have choppy playback, etc.

(In reply to comment #21) > It looks like it's directly related to video canvas size it is Bug 448914 Generally we have improved a lot.. Now I am able to play medium sized video at http://www.double.co.nz/video_test/test4.html in my old Celeron 1.20Hz PC But there is an issue of Tempo change, see Bug 498560 The low resolution one there runs at 80% CPU And even the high resolution can play.

Performance is still bad for me. From my observation, it appears that the current buffering implementation is seriously inadequate and is what is still holding things back. If Mozilla fixed that, things would be significantly better. Playing the video linked in Comment 22, playback is initially really choppy and CPU is high, but then things smooth out for a few seconds then go choppy again and so on. So it looks like buffering may be the remaining Achilles' heel.

watz ur processor speed, I wonder what is the speed off the computer of an average user.

My processor speed is in Comment 0; however, like I stated, this looks like a buffering issue. If I pause video playback and wait several seconds, video playback is okay for a few seconds (depending of video quality) then goes choppy again. If I pause again for several seconds video playback again is okay for a few seconds. Pausing for a really long time does not help, because the video/audio buffers does not appear to be all that deep. Even with the low resolution video in Comment 22, where CPU utilization is averaging about 50 % on my system, stuttering and CPU utilization spikes initially, then stabilizes for a few seconds then spikes again, etc. Pausing for several seconds and resuming playback returns to smooth playback for a few seconds, etc. So this has to be something to do with an inefficient/slow buffering mechanism, as far as I can tell. In other words, the reading/buffering mechanism itself seems to need a serious speed bump. Video portions already in memory play fine.

what I heard is we cant use video acceleration to achieve speed as other clients and plugins do. These is to make VIDEO to be manipulated like other HTML contents. But feel now we may want to consider selectively switching to video acceleration for those video performing really bad.

(In reply to comment #25) > My processor speed is in Comment 0; however, like I stated, this looks like a > buffering issue. The controls show how much of the video is buffered. The cache holding the buffered data is upto 50MB by default I think and shared amongst all videos on the page. Can you load a video and allow the entire thing to be buffered (or as much as it can) then play. What is playback like in that case? When you play and it starts to stutter can you look at the controls and see if there is any buffered data left to play? A 'throbber' should also appear when buffering - if you don't see that it's unlikely to be a buffering issue. Given you are on windows, bug 498770 may also have an effect. Another thing to try is start the video playing then 'right click' and choose 'hide controls'. This will remove the progress indicators and drop cpu usage used to update these. Does that improve things at all? VLC will always have a lower CPU % when decoding/playing as it can take advantage of fast screen writes, doesn't have to compose with existing screen content, and doesn't need to raise DOM events on every frame of the video.

(In reply to comment #27) > Can you load a video and allow the entire thing to be buffered (or as > much as it can) then play. What is playback like in that case? One thing to watch out for is that we don't buffer videos beyond the first frame by default now (unless the element has the autoplay or autobuffer attribute set), so if you want to let the entire video buffer (and it doesn't appear to be doing so automatically), click play and then pause and then we'll buffer up to the 50MB limit Chris mentioned. The other thing related to the autobuffer attribute is that we might stutter a bit when we first start playback of a non-autobuffer video. This is because we don't have much buffered when the user requests playback, and it takes a little while before the data resumes downloading once playback is requested. We could probably improve this behaviour somehow, but it's tricky because we can't really guess how long to wait to buffer before starting playback. Note that you would only see this problem once, when you first start playback, and it sounds like you're seeing buffering issues throughout the entire video. > Given you are on windows, bug 498770 may also have an effect. Bug 496529 will help improve decode performance, too.

Thanks for all the feedback. Did more testing and you're right; it's not a buffering issue. After restarting Firefox (it had been running for several hours and used for watching flash videos, etc.) things smoothed out. So my best guess is that it may have been a result of Firefox's memory management kicking in. Also, "hide controls" does indeed improve performance. I'll wait for bug 498770 and test then. Bug 496529 will have no effect for me, since my P3 supports only SSE and not SSE2. Thanks

Hmm. Bug 498770 only marginally improved matters. I'll keep this bug open as some of the other bugs in the Bug 476397 list, especially Bug 484814, may still improve things. (In reply to comment #20) > Has this gotten better enough now that I can remove this relnote? Let's wait for Bug 484814, if that's okay.

(In reply to comment #23) > Playing the video linked in Comment 22, playback is initially really choppy and > CPU is high, but then things smooth out for a few seconds then go choppy again > and so on. So it looks like buffering may be the remaining Achilles' heel. yeah, now I see similar problem for long videos, see bug 499554

(In reply to comment #28) > appear to be doing so automatically), click play and then pause and then we'll > buffer up to the 50MB limit Chris mentioned. So if playing starts after 50MB of video buffered, when do we start buffering again? or how often we buffer. As well as then in what size chunks we buffer again?

The handwavey explanation is that the cache will drop blocks once they have been consumed for playback, so once you begin playback, the cache can drop the played blocks and read new ones from the remote media resource. The gory details are documented here: http://mxr.mozilla.org/mozilla-central/source/content/media/video/public/nsMediaCache.h#101

I believe I am also experiencing this bug. I reported it against Fedora 11. Check out https://bugzilla.redhat.com/show_bug.cgi?id=509229 , I've included a video attachment of my screen while the bug was doing its thing. ( Ignore the quality of the video, as it was taken with my cheap camera )

(In reply to comment #34) > https://bugzilla.redhat.com/show_bug.cgi?id=509229 That is exactly bug 499554

Browser version: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6 PC: Windows XP SP 3, AMD Athlon Barton 1,9 Ghz, 1 GB RAM The videos in the provided links play choppy for me, however, the video at http://www.spreadfirefox.com/5years/en-US/ is totally unwatchable. The audio stutters so much and so rapidly that it becomes unbearable. CPU usage ranges between 80-90%

(In reply to comment #36) > http://www.spreadfirefox.com/5years/en-US/ is totally unwatchable. The audio On that video there should be some mechanism to lower quality to play video pay smoothly, may be a link below video, something similar to Quality: [LOW] [MEDIUM] [high] Do we have bug for that?

i found the choppy performance at various of bitrate from 400kbps to 1200kbps. If hardware acceleration of the only way to get decent quality of video, the whole HTML video saga would be meaningless. Who gonna use it if the video performance would be abysmal?

The combination of patches from bug 531340 and bug 484814 have resolved this for me, so closing this. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 ID:20100409040127 http://hg.mozilla.org/mozilla-central/rev/5022d0baf80c