info@thesaddj.com wrote:
HI everybody, thanks to all, i solved the issue. But is still not clear to me what's happening. I mixed the different suggestions you gave me (cause independently no one was working) and i got this:
[gemhead] | [pix_film]/[colorspace RGB( | [pix_alpha] | [colorRGB] | [alpha] | [pix_texture] | [rectangle]
it looks a bit weird but it's working and my cpu is drinking a coffee while i mix four videos of 160/200mb each. but I'm really keen to understand where was my problem... as Philippe said i have to send the [colorspace RGB( message first and then load videos. [pix_alpha] seems to be the obj making the work done, but
well, [pix_alpha] will overwrite whatever alpha is in the channel. so if the original alpha is 0 (full transparency), [pix_alpha] will eventually raise this to 1 (full opacity), thus making your object not disappear.
what bothers me a bit is the use of RGB rather than RGBA in the colorspace message....
anyway i had to add [colorRGB] to be able to change transparency.
well, that was the original idea, wasn't it?
@IOhannes: i'm on windows xp pro. do you think it could be because of this?
don't know, it just makes it easier to debug...(e.g. on osx the default colorspace is YUV, having no alpha-channel at all, which would make it unlikely that each pixel would have an alpha of 0) which movie are you opening? an AVI, a QuickTime movie?
could you share it for testing purposes? or does it happen with the example movies that come with Gem as well?
what do you mean with video-importer?
i mean the actual backend that reads the file and passes the frame to pix_film. e.g. the Gem code that accesses QuickTime/W32 or DirectShow or gmerlin. if the movie does not contain an alpha-channel, "somebody" has to provide values for alpha when doing RGBA; there might be a bug there...
fgkafdrt, IOhannes