At 8:52 AM -0800 1/4/2011, imrazor wrote:
Interesting. I thought the reason that VLC handles video playback on
older Macs (this is true, right?) was that it offloaded a lot of
video processing to the video card, whereas iTunes/Quicktime did
not. Have I been misinformed?
VLC does NOT use the GPU for video decoding on the Mac. Since OS X
10.6.3 includes a new API for accessing the GPUs, support in VLC may
be added in the future.
In general, VLC is so successful at what it does because it is
extremely well written. Imagine how powerful QuickTime could be if
it was as well done! ...Case in point, since you mentioned
iTunes... It is pitiful that an app such as Audion can play streamed
radio using less than 5% of a 200 MHz CPU but iTunes on the same
computer uses over 20%!
I think there are some misconceptions as to what does what...
Video data is encoded / compressed in some way. The "player" must
read that data, decompress it, decode it (turn it into usable
frames), render the frames into video data, then display it on your
screen - umpteen times per second. ...It is only those decompress
and decode functions that are included in the "codec" module.
The question is which of those steps is performed where?
Normally, everything from "render" on is done on the video card, in its GPU.
The codec - the software module that does the decompression and
decoding - can also benefit from doing things in the GPU. But to do
so, it needs to know how that particular GPU works, and what special
features it has available (eg: MPEG-2 and more recently MPEG-4 H.264
decoding). Apple tries to make this easy(ier) to do by providing
things like the OpenGL and QuickTime frameworks and providing APIs
into Quartz. Still up to the codec's author to take advantage of
them tho.
But wait -- let's make it more complicated! LOL What if the video
player supports filtering and such, as VLC does? Well, then you give
the GPU the data to crunch, *then take it back*, apply those filters
and such using the main CPU, then pass the data off to the GPU
*again* for rendering and display. ew.
A good example of a codec author failure is, of course, Adobe's
Flash. Instead of cleaning up their own code and taking advantage of
the great tools that Apple provides, they spent millions on a
b*tchfest about Apple refusing to give them direct access to the
hardware.
Another example is the development of the "name brand" DivX codec.
Why is it so abysmally slow and unstable, while Perian runs circles
around it???? LOL
At 10:16 AM -0700 1/3/2011, Bruce Johnson wrote:
Streaming video is MUCH more CPU intensive than DVD playback.
To elaborate a bit... DVD-Video is low-compression MPEG-2. Easy to
play, even on a very slow machine. Streamed video is highly
compressed Flash or MPEG-4 H.264. Very CPU intensive to decompress
and decode -- and that's before the GPU involvement (if any).
Now, to get back to the OP's problem... There is something going on
BEYOND bus and processor speed and all that total guesswork
hand-waving. On my 300 MHz Smurf, I can view YouTube video
*smoothly* with &fmt=5 added to the urls. If my *G3* Smurf can do
that, then his *G4* Cube can certainly do it. But he says not. So
there is something else happening. (waiting for specific answers to
the questioned I posted on 1/3).
- Dan.
--
- Psychoceramic Emeritus; South Jersey, USA, Earth.
--
You received this message because you are a member of G-Group, a group for
those using G3, G4, and G5 desktop Macs - with a particular focus on Power Macs.
The list FAQ is at http://lowendmac.com/lists/g-list.shtml and our netiquette
guide is at http://www.lowendmac.com/lists/netiquette.shtml
To post to this group, send email to g3-5-list@googlegroups.com
For more options, visit this group at http://groups.google.com/group/g3-5-list
