[GEM-dev] pix_freeframe and m_instance

[james tittle]

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