pix_filmDarwin - like chris mentioned, this has been improved in the same manner as pix_filmDarwinYUV, meaning much improved frame access and speed...
pix_dot - saw this lying around without function in cvs since inception, finally decided to make it work...kind of like an ascii/halftone filter, it abstracts a picture into large dots...YUV on the way...
...also changed around member initializers in GemPixUtil.h to reduce the 800+ compiler warnings it gave in gcc3.1...
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?
and as i am now doing a workshop with some macers, would it be much of a problem to add an alias from [pix_videoDarwin] to [pix_video] (does this apply to [pix_film] too ?) i think Gem-patches shouldn't be that platform-dependent....
pix_dot
- saw this lying around without function in cvs since inception,
finally decided to make it work...kind of like an ascii/halftone filter, it abstracts a picture into large dots...YUV on the way...
ah great, thanks (i forgot to do it then, and had never the time and leisure to do it afterwards)
mfg.as.rd IOhannes
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.
and as i am now doing a workshop with some macers, would it be much of a problem to add an alias from [pix_videoDarwin] to [pix_video] (does this apply to [pix_film] too ?) i think Gem-patches shouldn't be that platform-dependent....
pix_film already has the alias, but pix_video doesn't at the moment. 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.
you might want to familiarize yourself with the differences between OSX and the other GEM versions, like using pix_texture2 for rectangle textures, and using YUV instead of RGB for much better performance.
cgc
On 11/4/03 9:27 AM, "chris clepper" cclepper@artic.edu wrote:
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.
there are two problems here aren't there? - different underlying libraries - different PD message interfaces
given that most of the libraries can be used on most platforms, it would be good to have encapsulated film loading classes. even better would be to make these classes dynamically loadable, so that you wouldn't need to recompile gem to add/remove support for the various libraries. We could also hopefully avoid all the nasty #ifdefs in the code that way too.
I've been trying to work out how best to do this for QuickTime support under windows. It would also be good for pix_filmDarwin to be moved into a filmQuicktime class so that I could then add QTML support for QT for Windows and have it exposed within [pix_film]. Likewise DirectShow codec support for pix_film on windows.
and as i am now doing a workshop with some macers, would it be much of a problem to add an alias from [pix_videoDarwin] to [pix_video] (does this apply to [pix_film] too ?) i think Gem-patches shouldn't be that platform-dependent....
The basic structure of the pix_video code and behaviour doesn't map well to windows video capture APIs... that's why I chose a different set of messages and behaviour for pix_videoDS.
If we're going to consolidate the video capture code, I think we should rework the pix_video messages and behaviour.
Daniel
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
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
On Thursday, April 10, 2003, at 06:45 PM, zmoelnig@iem.at wrote:
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?
...sorry, haven't had a chance to look at this new approach, but I wonder how it would deal with opening films in different ways (again with the rgb/yuv thing)...I mean, any of those formats could be used to produce an rgba OR a yuv output (like we do with quicktime now), but I'm not sure that this could be done dynamically with a simple message...
and as i am now doing a workshop with some macers, would it be much of a problem to add an alias from [pix_videoDarwin] to [pix_video] (does this apply to [pix_film] too ?) i think Gem-patches shouldn't be that platform-dependent....
...changing this to [pix_video] has been an oversight ;-)
pix_dot
- saw this lying around without function in cvs since inception,
finally decided to make it work...kind of like an ascii/halftone filter, it abstracts a picture into large dots...YUV on the way...
ah great, thanks (i forgot to do it then, and had never the time and leisure to do it afterwards)
yep! it still needs some changeable variables and such...
l8r, jamie
-
chris clepper -
Daniel Heckenberg -
Me -
zmoelnig＠iem.at