QT and 10.1 major speed problems

Just finished upgrading to 10.1 and am very impressed. Apps launch easily twice as fast and QT runs fine. I could not watch the full screen version of the Lord of the Rings trailer under OSX before. After checking this thred out I fired it up, while playing iTunes and it is marvelous. No out of sync audio or jerky video.

I'm happy with OS X 10.1

G4 400 AGP, 512MB RAM.

DOH
 
Originally posted by Makosuke
I'm going to have to partially disagree with the porting theory; I do think it has to do with a "get it working" port, but since the problem is just with the MPEG decoder, I'm a bit skeptical that it has much to do with threading issues.
heh.. I actually did a bit more testing and I'm now more convinced it's a threading issue :)

I opened the tomb raider sorensen trailer and a 3ivx movie. started one, tried the menus. pretty fast, but still not up to the non-qt player standard. I started the other as well, and the menus are slower. If at this point you switch to another app, bingo, the menus are fast again.

If the qt player was a modern carbon app with threading being done by the mach kernel, then we'd see no slowdown whatsoever. But since the threading is done by the old event model, it's managed by the cooperative process of the player. So the more cpu action required by the movie playing, the less available to do the menu routines.

but some programmer check me, I'm a bit rusty on my osx internals..
 
Originally posted by Makosuke
I'm going to have to partially disagree with the porting theory; I do think it has to do with a "get it working" port, but since the problem is just with the MPEG decoder, I'm a bit skeptical that it has much to do with threading issues.
although yes, I agree that the mpeg decoder could use some more optimization :)
 
Originally posted by soellman

sure, why? it plays just fine fullscreen, while I have itunes doing visualizations in the other monitor. no slowdown whatsoever in qt, although the itunes vis has a pretty slow framerate :)

works like a champ.
You're obviously not using a 500mhz G3 then. If I hit 'esc' (thanks for the tip, BTW) Quicktime takes about 10 seconds of stuttering before its visible in the window. If I grab the window and drag it around, the movie pretty much stops playing, although the audio never skips. It's pretty horrible.

Playing both FotR and Harry Potter at the same time was a joke, neither one worked very well at all. This system has 384mb of RAM (ibook dual/USB), and the only other open applications are CPU Monitor and Mozilla.
 
I downloaded the largest file size of the lord rings file. not full screen. it played ok and when i move the window while it plays it was much better. but when i play local mpeg files and try to move the mouse in the file menues etc it is slow to respond. also the files are from the news groups. QT player is the issue yes.

Also, does anyone know when mac os 10 and QT will be able to play all the avi and mpeg files windows can play? i have tons of avi and divx etc and mac won't play them nativly at all.
 
Also, does anyone know when mac os 10 and QT will be able to play all the avi and mpeg files windows can play? i have tons of avi and divx etc and mac won't play them nativly at all.

X can already play all those divx videos (as well as the related 3vix codec) via a handy freeware plug in available from http://divx.jamby.net/

Just drop it in the QT folder and boom! System-wide, native divx from within any QT-aware app--not even a restart necessary. For all the months of work on the Classic MacOS divx project, it never even approached that. Still a few sound issues, but all in all, very cool, and under active development.

As for the rest of the formats covered under the .avi label, you've mainly got Indeo 3.2, 4, and (most popular) 5, plus i263 and a couple of very old MS codecs. The old ones are obsolete, and you can (via plug ins available from Intel) play the Indeo codecs through classic. Intel apparently sold the codecs to another company, though, and I have no idea what their port plans are. On the bright side, I'd say the majority of new .avi media is divx compressed. Oh, and that i263 codec was a slightly modified (just enough to make it proprietary) version of the standard h263 streaming video codec, and there never was a Mac version of it.

As for windows only MPEG videos, are you thinking of MS's MP42 codec? MS Media player will probably pick that up in the future, or (when they finalize MPEG4) it'll be included in Quicktime... I think. That whole scene has always confused me.

heh.. I actually did a bit more testing and I'm now more convinced it's a threading issue

I opened the tomb raider sorensen trailer and a 3ivx movie. started one, tried the menus. pretty fast, but still not up to the non-qt player standard. I started the other as well, and the menus are slower. If at this point you switch to another app, bingo, the menus are fast again.

Hm... very good point. This isn't my strongest area, so you may well be absolutely right, although when I tried the same thing it worked a bit differently--QT player's menus did slow a bit with a load of (non-MPEG) movies playing, but not much, and although they were a tad snappier in another app, the movies skipped. That is, it seems like, when QT player is in the front, it gives horespower priority to videos, even if it slows down the menus. When it's in the background, the foreground process takes some more CPU (as it should), which makes it faster but causes the movies to skip. Sounds like the way I'd want my scheduling to work... but of course, maybe I'm completely misinterpreting this, and even if I'm right QT Player's behavior might still be due to non-modern threading rather than intentional planning.

In any case, though, the point I was originally trying to make was not that QT player was or wasn't a well behaved X app, but that the main problem with unresponsive menus and poor performance has more to do with the MPEG decoder than threading one way or another. Who knows, maybe the bum MPEG decoder eats up all the (few?) threads that Player has available, and that's why its so unresponsive...

But again, my knowledge of the subject is shaky enough that I could be entirely wrong on all this...
 
Originally posted by ink

You're obviously not using a 500mhz G3 then. If I hit 'esc' (thanks for the tip, BTW) Quicktime takes about 10 seconds of stuttering before its visible in the window. If I grab the window and drag it around, the movie pretty much stops playing, although the audio never skips. It's pretty horrible.
No, no I'm not :)

Performance-wise, I can't tell if there's a problem, but that's because I've got a more modern system (dp450/1.4gig ram).. I hadn't tried it with a g3/500!

And as far as divx avi's go, we can play them with the jamby codec, but sounds is still screwy because of a quicktime bug. I think it's that qt can't read certain kinds of mp3 encoding out of avi files. But that is a known bug by apple, and should be fixed in one of the 10.1.x updates I'm assuming. And there's still plenty of altivec optimization that can happen in ffmpeg (the engine inside the jamby codec) so it should work better in older machines (again, not something that I see).
 
I have an iMac and it works fine! AND HERE'S WHY:

I have my monitor set on thousands (not millions) of colors and the screen res. is at 1024x768. My thinking is that your G4 is set at millions (doesnt' really look different if you're in thousands but the speed is a hellofalot faster) of colors at 1600x1200 resolution. Is my thinking partially correct?
 
Maybe you have too much RAM? ;-) I have a ... check my sig ... with 320M RAM and my main display is a Radeon and my other display XClaim VR 128, both at millions of colors. It takes up both processors in full on the 128, and about 3/4ths that on the radeon. The 30M movie kicks ass, as does my clean install of 10.1

As for your hatred of sorenson, I happen to love sorenson, but that is not an issue with QuickTime, Sorenson is its own company. They just make one helluva codec. QT is a killer framework, and it's become pretty happy on Mac, Windows, and Linux now. I think it needs to become the de facto standard in addition to the MPEG 4 standard. Granted it'd be making me angry if it didn't play stuff ... what video card are you on?

And finally ... whoever put that movie together kicks ass. It uses the QT framework to dynamically display its own slider, uses 2 stills with live QT fades so as to keep quality high and reduce codec abuse. One of the classic problems with low bandwidth (epitomized by cinepak) is dancing pixels. This is a sweet way to get clean stills without squandering away your bandwidth. And I can't copy it, good for them, ... maybe I'll slap it full screen onto VHS. :) Wonder if they encoded that VCR suck signal into it? ... nope, they didn't. Anyone want a copy? it's analog. ;-)
 
For the heck of it, I just tried the 480 FF Movie trailer and the LotR trailer on an old beige 266 with 10.1. The LotR trailer had sound, but the video was essentially not moving... but even their stats said at least a G3 300, and Classic was about the same. (On the other hand, the menus and controls in QuickTime Player were still more responsive than on my DP533 with a MPEG video half that size playing.) The smaller trailer (still big) played with just a tiny bit of stuttering, and actually dragged surprisingly smoothly--jerky video while dragging, but it was still moving and the window moved smoothly. Again, the same video played with a little less stuttering in Classic, but all in all, I was impressed with how close the X performance (at least with the Sorenson codec) was in comparison.

On an unrelated note, I forgot to mention something kind of funny: Try opening an MPEG movie in a Classic version of QT Player and check out the CPU monitor--at least on my box, it pulls probably a third of the CPU power of the same movie in QTX. There's evidence if I ever saw it.
 
Sorry to dredge this thread up, but I just discovered something very interesting (if not useful to anybody but QT developers) about the slow MPEG performance in QTX: It's the audio's fault.

I happened to be messing around with a demuxing program, and when I played the video stream I noticed that the player was entirely responsive, and the processors were barely even noticing it. But when i played the audio... boom. Incredibly sluggish response from QT Player, processors probably 2/3 of max. And there you have it.

Since MPEG1 layer 3 audio is fine (I think we'd have all noticed if that one wasn't ok), and an MP2 clip I tried worked well too, I guess it's just MPEG1, layer 1 audio that chokes QuickTime. Of all the things to cause problems... I guess if you encoded one with MP2 (or MP3, I suppose) audio it'd work ok.

Funny, because I now vaguely remember that classic QuickTime used to have problems with sluggish response on MP2 (not MP1) audio way back before it even supported MP3. I wonder if this is some vaguely related bug cropping up years later, or just a coincidence.

Anyway, I just had to tell SOMEBODY about my little discovery.
 
I'm on a B&W G3/450, and my only complaint with Quicktime is when playing some MPEG files. I can't drag the window or control the volume without clicking and holding for several seconds and even then it's choppy. Native Quicktime (.mov) files play flawlessly and I can drag them around fine. Even DivX and my hacked DVD player work better than MPEG files. Just odd.
 
Originally posted by vertigo
I'm on a B&W G3/450, and my only complaint with Quicktime is when playing some MPEG files. I can't drag the window or control the volume without clicking and holding for several seconds and even then it's choppy. Native Quicktime (.mov) files play flawlessly and I can drag them around fine. Even DivX and my hacked DVD player work better than MPEG files. Just odd.
That, vertigo, is exactly the bug we've been talking about for the past dozen or so posts. Although there are some complaints about overall speed, the only real problem is a bug in the MPEG decoder that causes it to suck up way more processor power than it should need, and that's why the windows drag terribly when an MPEG clip is playing.
 
Back
Top