[PD] Re: Gem for OSX

[chris clepper]

Ivan suggested that this be forwarded to the list as it would help 
clear up some possible confusion about GEM, OSX, RGB vs YUV, etc:

At 7:00 PM +0000 2/24/03, Ivan Franco wrote:
>I'm talking about the basic help files for performance comparison.
>I'm running a Ti 500 Rev.A (same cheap card as yours :-) )
>Yes, I've notice the yuv run much faster, but I was refering to the 
>basic pix_film.
>I've only noticed there was a yuv movie player a bit after the last 
>mail. Anyways, can
>it be used together with all the other pix_ processing stuff?? And 
>are all the rest of the
>yuv objects in the extra help files you provide? Also I noticed 
>there were to yuv players...
>
>Thnx a lot
>>Ivan


the basic pix_film uses RGB and it has to convert the yuv data in the 
compressed video file to RGB, which is quite slow.  not all of the 
pix_ objects can do yuv at the moment, so you might have to use some 
yuv_ objects right now.  if you want to use RGB pix_ objects then i 
recommend using the Animation codec since it's the only codec that 
uses compressed RGB.  this will remove the slow YUV->RGB conversion. 
incidentally that conversion was done in hardware by 
quicktime/quickdraw until recently (QT6 changed it?).  i'm trying to 
figure out how to get it back in OSX.  in general the OSX version is 
really designed to use YUV the whole way, in fact it's the only 
platform that can do it at the moment.

there are two yuv players (yuv_film and pix_filmYUV) that are 
identical.  since all of the yuv_ objects are in the process of being 
rolled into the pix_ ones there is the pix_fillmYUV as a transition 
object.  at some point there will probably just be pix_film that does 
both RGB and YUV based on a message or argument, but right now that 
doesn't work because openGL doesn't like switching color-spaces on 
the fly.

docs and a tutorial are really lacking at this point so you'll have 
to bear with it for the time being.  on the other hand if you are a 
fantastic doc writer maybe you can help out...

cgc

the last part about 'fantastic doc writer' is open to anyone.  i 
personally would prefer a non-developer to write the tutorial because 
the people writing the code are generally pretty bad about writing 
'howto' information.  also, some distance from the project might make 
the whole thing more objective.