User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080828020913 Minefield/3.1a2pre (like Firefox/3.0) Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1a2pre) Gecko/20080828020913 Minefield/3.1a2pre When I try to watch any Theora video from http://www.double.co.nz/video_test/ on my PPC mac, no video is shown, Minefield stops responding and eat 100% CPU. Reproducible: Always Steps to Reproduce: 1.try any video from http://www.double.co.nz/video_test/ Actual Results: minefeld freezes, I have to force quit. Expected Results: video should play.

Testing on PPC OS X 10.4.11 (with today's Minefield nightly) I see a hang-on-quit (and FF eating a lot of CPU) when I visit http://www.double.co.nz/video_test/test1.html: But I'm able to navigate around, close the window, and open a new window. FF only truly hangs when I try to quit. However when I visit http://www.double.co.nz/video_test/test2.html FF doesn't consume more CPU than normal, and I see no hang on quit. In both cases clicking on the play and pause buttons has no result -- not even to make the problem worse. So we really have two problems here: 1) The examples at http://www.double.co.nz/video_test/ don't work on PPC Macs. 2) Sometimes they eat lots of CPU and cause a hang-on-quit. I've no idea why for either case.

Side note: I don't see anything relevant in either the browser's (JavaScript) error console or the system console.

Here's a gdb trace of the hang-on-quit I see after visiting http://www.double.co.nz/video_test/test1.html. I closed all windows before choosing Quit Minefield from the Minefield menu. I tested (on a PPC Mac running OS X 10.4.11) with an opt build (of mozilla-central code) containing debug symbols. The code was pulled yesterday. It's interesting that the main thread is stuck processing input for the Ogg decoder, and also (at a slightly higher level) in the cycle collector. http://www.double.co.nz/video_test/test1.html contains three videos. And after visiting that page, there are three threads (besides the main thread) processing nsDecoderEvents. But by the time of the hang, there are only two such threads left. My guess is that you'll get a hang whenever you quit with more than one (non-main) thread processing nsDecoderEvents. This is normally an extremely rare occurrence. But if (as on a PPC Mac) <video> tag decoding (or Ogg Theora decoding) doesn't work, every time you try to open another video you open another thread.

> My guess is that you'll get a hang whenever you quit with more than > one (non-main) thread processing nsDecoderEvents. This isn't quite true. I just tried playing the videos at http://www.double.co.nz/video_test/test1.html simultaneously (on my Intel Mac running OS X 10.5.4), then quitting while all three were still running. I didn't hang on quit. I'll bet the number of threads is still relevant, but they need to somehow be "stuck" to see the hang.

The hang on PPC might be an endian issue. Usually the third party media libraries detect things like this at the configure stage and I replaced these by setting values in our own Makefiles where needed. I haven't done this for endian detection. Yes, if the background threads block for some reason then shutdown will hang. There are some places where this happens in the current code but bug 449159 addresses these as well.

(In reply to comment #5) > Yes, if the background threads block for some reason then shutdown will hang. > There are some places where this happens in the current code but bug 449159 > addresses these as well. Videos still don't work and cause a hang on quit after the landing of bug 449159.

I missed an endian configuration flag in liboggz, which is used for the ogg decoding. This is probably a contributing factor to the problems. I'll find someone with a PPC machine that can do builds to do some testing.

hi all, yes, we thought the endian may be the issue here, too, at archive.org confirmed the last pub avail FF3.1 beta still has issues. this time, at least, the audio plays after a delay (but no video). (perhaps it is downloading the entire file first before it can get to the audio?) eg: http://h02.us.archive.org/~tracey/_/stream.php?theora=BraveNewFilmsFoxAttacksObama/foxattacksobama320.ogv i tested FF3.1 beta last night w/ these test items on my MB Air and everything was swell. so anyway, i have a PPC mac here at work if you'd like me to try some things.

We still have a fair number of PPC users and so long as we are going to officially support PPC then we have to block on this.

Chris, can you attach the patch you thought might help here? I can test it. So can Steven.

I don't have a patch yet. I need to work out how to detect endian and correctly set the build parameter required by liboggz. Failing that, how to detect PPC.

NSPR #defines IS_BIG_ENDIAN and IS_LITTLE_ENDIAN, but maybe that doesn't help.

This patch changes the endian configuration in the media third party libraries. Can someone build and apply this on a PPC machine and tell me if it works? If it confirms that it fixes the issue I'll integrate it into the build system to detect the correct endianess.

ok, just built firefox/minefield from source on work PPC and ran minefield OK. just applied patch and am recompiling... will revise/reply ASAP i know something...

It recompiled and I had mixed results. My "head of mercurial" build did not play any audio or video best I could tell. After the patch and rebuild, the audio started working so that was nice. The video was kind of "ghostlike" (something like only the Y in YUV was showing, etc.?) Perhaps there's another couple endian switches needed somewhere? (In reply to comment #14) > ok, just built firefox/minefield from source on work PPC and ran minefield OK. > just applied patch and am recompiling... > will revise/reply ASAP i know something...

I get results similar to Tracey's. Testing with test1.html and test2.html, the audio seems to be OK (though my PowerPC G4's speaker is on its last legs, so I can't be sure about that). But the video is definitely "ghostlike" (many parts of the picture missing), and those parts that remain are definitely pink/purple. I can no longer reproduce this bug's hang on quit (as described in comment #1) with an unaltered Minefield nightly. So that problem seems to have been fixed by other means.

Here's a screenshot of http://www.double.co.nz/video_test/test2.html made on a PPC Mac using the patch from comment #13.

Here's another screenshot of http://www.double.co.nz/video_test/test2.html, made on an Intel Mac, using a recent Minefield nightly. I tried to pause this video in the same place as I paused the one from comment #17.

(Following up comment #16) > Testing with test1.html and test2.html, the audio seems to be OK > (though my PowerPC G4's speaker is on its last legs, so I can't be > sure about that). I connected another speaker to my PowerPC G4 (one that works fine) and found that the audio *isn't* OK -- it has lots of gaps/breaks.

FWIW, audio has been OK for all the .ogv that we are creating here at archive.org that I've tested. (we're using ffmpeg and libtheora, then oggz-merge to join them) (In reply to comment #19) > (Following up comment #16) > > > Testing with test1.html and test2.html, the audio seems to be OK > > (though my PowerPC G4's speaker is on its last legs, so I can't be > > sure about that). > > I connected another speaker to my PowerPC G4 (one that works fine) and > found that the audio *isn't* OK -- it has lots of gaps/breaks.

Thanks for the responses, that is very helpful. I'll see if I can find out what to do about the video image issue.

This adds a possible fix to the PPC 'ghostlike' problem. Can someone on a PPC give this a try? Remember that this patch will only work on PPC. Once I see it works I'll work out the changes needed to get both PPC and Intel working.

ok, i just applied the patch and rebuilt on my PPC here at work and it's still ghostlike, unfortunately. it may be a bit different/better, but i'm not sure. the minefield i ran on test clips certainly was not playing correctly, though. (i was a big Dr Who (tom baker, please) fan growing up -- it's a lot like when they applied a "negative film" effect when the Daleks (t)roll around and shoot people 8-) i can try to get the most recent version of the source code on monday since i was building from a nov19 build (not sure that will make a difference, but we can hope!) happy new year!

(In reply to comment #23) alright did a mercurial update to latest as of today (removed any changes i did from your patch), re-applied your patch, cleaned/rebuilt. still problems -- but a bit different/better. kind of "negative film" like but also color blocks. here's a good example screenshot: http://www.archive.org/~tracey/downloads/theora.jpg

I'm going to demote the importance of this bug. We simply can't get it done for beta3.

We've been able to get playback working correctly on a PPC machine now. I'll get a patch together tomorrow.

adds the yuv2argb routine for PPC

I rolled it all into one patch. Changed detection of powerpc to using nspr's IS_BIG_ENDIAN define.

Pushed to trunk: http://hg.mozilla.org/mozilla-central/rev/1f87701751d7

yay! i just updated to the head of the mercurial trunk, rebuilt from scratch, and *confirmed!* all tested clips here are working. (and that will mean now ~200,000 of our archive.org movies will work in FF3.1 when it ships!!) woots! thanks chris double et al!

Fixed for FF3.1 beta 3! http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e181257b2639

Thank you all for the fix. However we now have bug 462667 video are choppy and use 100% CPU.

Can you provide details of your machine? CPU, speed, etc, on that bug.

(In reply to comment #34) > Can you provide details of your machine? CPU, speed, etc, on that bug. Mac Mini PowerPC G4 1.25Ghz Mac OS X 10.5.6 I have the exact same symptoms described on windows in the first post of bug 462667 I can use VLC or Quicktime to play perfectly any ogg video from http://tinyvid.tv/ but they are a little choppy and use nearly 100% cpu power in firefox.

https://litmus.mozilla.org/show_test.cgi?id=7056 had been added a while back to Litmus so it should cover this case.

This looks good using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre. I will test on 10.5 as well before verifying.

Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090204 Shiretoko/3.1b3pre the videos seem to play fine, but I do see high CPU usage as soon as I start playing http://tinyvid.tv/show/22axtzbrwetr4, for example. Machine specs are: Dual 1.8 GHz Power PC G5 running 10.5.6 1.25 GB RAM This is the same machine I tested in Comment 37 but I did not notice the CPU issue using 10.4. I can verify this bug is fixed on 1.9.1 regarding the hang issue and I can either file a new bug for the CPU issue or add to the existing bug mentioned in Comment 33 (although I do not see that the videos are really choppy)

Also, using Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b3) Gecko/20090304 Firefox/3.1b3 ID:20090304214853, the videos were able to play in their entirety without hanging the computer. The video, though, was choppy and and led to high CPU. As Marcia said in the previous comment, should a new bug be listed for the choppy issue or not?

Please create a new bug for the choppy ogg video issue on PPC, and perhaps relnote nom that bug. The original issue in this bug is fixed and verified on: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090310 Shiretoko/3.1b4pre and Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090310 Minefield/3.2a1pre

(removing relnote as this bug is fixed in b3)