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...