[PD-dev] [GEM] evenMORE HOT cvs action!

zmoelnig at iem.at zmoelnig at iem.at
Fri Apr 11 22:55:09 CEST 2003


i think daniel has answered most questions.

Zitiere chris clepper <cclepper at artic.edu>:
> >Zitiere Me <tigital at mac.com>:
> >
> >>  pix_filmDarwin
> >>	- like chris mentioned, this has been improved in the same manner
> as
> >>  pix_filmDarwinYUV, meaning much improved frame access and speed...
> >
> >great.
> >anyhow, i'd like to move all the OS/lib-dependent film-stuff into 
> >film*.cpp files.
> >any objections?
> 
> can you explain exactly how the new filmDarwin would be different 
> than pix_filmDarwin?  i think i see the usefulness for linux and the 
> many libs required to play various types of files, but the OSX stuff 
> looks exactly the same.  maybe we could use ffmpeg for OSX too, but 
> overall the platform dependencies are still there just under 
> different names.

what you mean by "OS-X stuff looks exactly the same" ?
i just copied and pasted the code from pix_filmDarwin into filmDarwin.

the idea was to se-arate the platform/library dependent code from the actual
[object] code.
I have to admit that the old way is really quite nasty, especially with
[pix_movie] inheriting from os-specific classes (yes, i know, that i have
introduced this)
of course the code would not change much, it is just about defining a
(hopefully) clean API that is used for accessing video-data from within Gem (or
even other libraries, but i have put the pixBlock-struct into the film* classes
for easiness)

> pix_film already has the alias, but pix_video doesn't at the moment. 
and with a platform-independent film* (or video*) class, there would be no need
for making aliases (which is really nasty)

> also, there is pix_filmYUV and yuv_videoDarwin because GL doesn't 
> like switching color-spaces for textures.  so right now the render 
> chain has to be initialized as YUV or RGB and kept that way or the 
> textures will get corrupted.
i haven't experienced this (problems with colourspace-switching) but this might
be a problem only for switching between very different spaces, like RGB and yUv.
RGBA/RGB/BGR/BGRA-switching normally works fine.

basically i have thought of specifying the format at load time (is this too
late?) of film-data.
what about trying to fix the problem in [pix_texture] ? are there any
possibilities for this ?

will there be a fix for the problem at the macOS side sometime ? (it seems to be
a problem with the macOS specific extension of openGL rather than with "normal"
openGL)

mfg.as.r
IOhannes




More information about the Pd-dev mailing list