i think daniel has answered most questions.
Zitiere chris clepper cclepper@artic.edu:
Zitiere Me tigital@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