chris clepper wrote:

There are lots of differences between the GEM versions already, a large one being the way video files are handled. The QuickTime API on Mac and Windows* extends far beyond the simple handling of video files, and includes support for things like VR and streaming. Also, the OpenGL implementations are different for every platform, the OSX version is using features specific to it like Rectangular Textures and YUV Texturing. My argument here is to not hold back development on one platform based on lack of features on the others. The core features of GEM would be the same, but the 'extras' would capitalize on strengths of each platform.

my idea was to use platform features as long as you could at least trick all other systems (that dont have this feature) to do something similar. like with pix_texture2 and rectangular textures. if macOS can make it faster, good use it then, on other OSs use a generic solution. if quicktime on Mac and Win32 supports streaming AND it is likely that there will be a similar mechanism for linux too, use it. If (expand all specific names like "quicktime" to anything) linux does NOT allow streamin via quicktime, please do not make a [pix_quicktime] object that does all kind of things on win/mac (like playing videos, streaming, etc) but not on linux. instead incorporate the video-playback of quicktime into the [pix_film] object, the streamin caps into [pix_webstream], the dv-caps into [pix_dv] and the PDF reader into [pix_acroread]

if there is no chance, that (in the near future) your special capabilities will be available on another (or one of those) platform(s), use an external mechanism like gemee

Right now GEM doesn't even play the same video files on every platform. There are platform/device specific objects like pix_DV and tablet etc.

well, pix_DV does not exist on any platform right now... (does it?)

BTW, what's gemee? I've never seen or heard of this before. It's not mentioned in the GEM docs or on any GEM site that I've seen.

gemee is a collection of externals for Gem (like Gem is for pd) by Günter. You should be able to find it on xdv.org (but maybe not, i couldn't reproduce this now) there were some experimental objects like using the asciiart-library (that's a good example: i don't think that there is an aalib on another platform, so this won't go into Gem)

cgc

*the Windows version of GEM doesn't use QuickTime right now, but it could be added fairly easily. Does this interest anyone?

yes

mfg.asd.r IOhannes

Hi Chris, list,

chris clepper writes:

*the Windows version of GEM doesn't use QuickTime right now, but it could be added fairly easily. Does this interest anyone?

yes - this would certainly be a good idea. There would be a little work in making the use of VideoForWindows or QuickTime (or DirectShow) transparent to the end user but selectable when people really know what they want to use.

I'm a little behind in the code revisions that have occurred with GEM since 0.87 but would like to assist in this process. I'd also like to look at these issues in GEM: - DirectShow support (which I've implemented for GEM 0.87) - Audio loading and handling within pix_film. - Separate threading for GEM objects to allow low latency audio to coexist with high CPU load video. (does the pdp code offer any insights for this? - I'll have a look)

Hopefully I'll have a bit of time over the summer break to look at these things. Is anyone else looking at these things at the moment?

On another note: I've done some experiments using Color matrix support in OpenGL 1.2 which could be a fast way of doing YUV to RGB conversion. On my nvidia geforce2go under win2k, color matrices aren't particularly fast - it looks like the color matrix is implemented in software in the drivers... combined with the fact that I can't see an easy way to handle the YUYV interleaving this probably means "Wrong way. Go Back"

daniel