...I'm currently trying to get [pix_freeframe] working again on osx (the plugin structure was changed for the freeframe 1.0 spec)...I've got the new bundle loading code working, but it's crashing when trying to actually processImage()...the most obvious problem in gdb is that the height and width don't seem to be passed to the plugin, and I'm having a hard time finding where this is filled out...this is working on linux, right?
jamie
james tittle wrote:
...I'm currently trying to get [pix_freeframe] working again on osx
i noticed on the freeframe-list...
(the plugin structure was changed for the freeframe 1.0 spec)...I've
when? or rather: the Gem-support for FreeFrame happened after FreeFrame-1.0 spec. the newest files i get are from 2004.
got the new bundle loading code working, but it's crashing when trying to actually processImage()...the most obvious problem in gdb is that the height and width don't seem to be passed to the plugin, and I'm having a hard time finding where this is filled out...this is working on linux, right?
as far as i can test (there are not that many plugins available on linux): pete's plugins work fine and gabor's ports of the xscreensavers do so as well (both are compiled by me)
the size of the frame is fixed for an instance of the plugin. therefore a check is done at the beginning of processImage(); on instatiation of a freeframe-plugin, a struct "vidinfo" of type VideoInfoStruct is passed, which holds the meta information of the frames.
btw, last time i tested, it also worked on w32....
mf.asd.r IOhannes
On Feb 8, 2006, at 12:06 PM, IOhannes m zmoelnig wrote:
james tittle wrote:
(the plugin structure was changed for the freeframe 1.0 spec)...I've
when? or rather: the Gem-support for FreeFrame happened after FreeFrame-1.0 spec. the newest files i get are from 2004.
...yeh, but I was using code for the dylib loading that came from pre-1.0 freeframe examples, in particular an example app called "FreeframeHostOSX"...but also, there's no mention of the change from dylibs to bundles in the developer documentation, and the freeframe sdk for osx only shows how to build plugins, not load them...curious documentation ommission! Even odder, it appears that we're the only open source implementation of freeframe on osx (gephex says they have it, but it's unreleased and likely not available on osx for the same reasons I faced)...
got the new bundle loading code working, but it's crashing when trying to actually processImage()...the most obvious problem in gdb is that the height and width don't seem to be passed to the plugin, and I'm having a hard time finding where this is filled out...this is working on linux, right?
as far as i can test (there are not that many plugins available on linux): pete's plugins work fine and gabor's ports of the xscreensavers do so as well (both are compiled by me)
the size of the frame is fixed for an instance of the plugin. therefore a check is done at the beginning of processImage(); on instatiation of a freeframe-plugin, a struct "vidinfo" of type VideoInfoStruct is passed, which holds the meta information of the frames.
...aha, a coupla well placed breakpoints later, and it seems that there's an osx problem with the format assignments at the start of processImage(): fr'instance, I loaded a movie with [colorspace RGBA<, but the m_image.format that gets passed to "format" is GL_YUV422_GEM! Obviously this isn't right, so i'll have to track down why...
btw, last time i tested, it also worked on w32....
...good to hear, I'll get it working here soon, I hope ;-)
thanx, jamie
curious...
On Feb 8, 2006, at 1:59 PM, james tittle wrote:
...aha, a coupla well placed breakpoints later, and it seems that there's an osx problem with the format assignments at the start of processImage(): fr'instance, I loaded a movie with [colorspace RGBA<, but the m_image.format that gets passed to "format" is GL_YUV422_GEM! Obviously this isn't right, so i'll have to track down why...
...I think I've found a subtle bug in our imageStruct conversions in GemPixUtil.cpp :-( Looking at imageStruct::setCsizeByFormat(), there's a horrible, confusing amount of #ifdef's to accommodate the fact that apple's native gem colorspace is YUV, but everybody else is RGBA...within these #ifdef's, there are "default:" cases for the switch(format){}, such that in the __APPLE__ platform, we never get to "case GL_RGBA:", because "case GL_YUV422_GEM:" is tested first, and on __APPLE__ is the "default", so it goes no further! I've removed this, but it still doesn't work, because now there's no a problem where we test for GL_BGRA_EXT instead of GL_RGBA on __APPLE__, so it just goes to default YUV again!
...so, I'm not sure what to do: sure, I could go ahead and also add GL_RGBA to the __APPLE__ test for GL_BGRA_EXT (also needing to do this for GL_RGB/GL_BGR...), but then I think we'll be in a situation where all processing inside of the freeframe plugins will be done on incorrect color channels :-\
...anyone see a way outta this?
jamie
ps: I'm also wondering if all of this backwards GL_* stuff will have to be changed for the intel macs...!
-
IOhannes m zmoelnig -
james tittle