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 ?
it probably needs to happen when the object is created, although it might be possible to test for the requested format when a film is loaded. right now everything is left up to the user, so they must pick the correct format for their uses. honestly, if it wasn't for Adobe and their Animation codec, OSX would default to YUV.
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)
if you are referring to the switching between RGB and YUV textures, i'm not even sure if it's a bug since no other platforms can even work with YUV textures at the moment. also, GEM is the only software that I know of that uses a full YUV QT and GL path right now*, so it's kind of hard to test against a 'working model'. this could just be a limitation of the hardware. i'll ask someone at Apple and ATI about this...
cgc
*maybe the new version of Shake does and Final Cut 4 might but it's not shipping until June.
mfg.as.r IOhannes