Hi Robert, Robert Osfield schrieb:
> Good news, thanks for your efforts on this. Will it be able to handle > multi-threading/multi-context windowing? Yes, I hope so, it's a full GraphicsWindow-implementation. I haven't tested multithreaded/multi-context-usage now, I am still struggling with events, and Cocoa. > Sorry but I couldn't quite work out the exact status of 64bit + > Quicktime. Will it be possible for use to move our present Quicktime > plugin across to work under 64bit, even if means emulation, or do we > simply have to disable the build of the Quicktime plugin under OSX. Quicktime itself is AFAIK not 64bit, there's a thin abstraction-layer (called QTKit) available for 32bit/64bit which routes the commands to a 32bit background-app playing the video-stream and handling the image back. For windows the SDK is only 32bit. I think disabling the quicktime-plugin for 64bit is the right way to go, without an alternative in place (ImageIO for example). >> Currently, I am against deprecating the quicktime-lib, because: >> >> 1.) it handles images default for OS X > > Which images does Quicktime support that we don't have other plugins > for? Ideally I'd like to see us have cross platform support for all > types of imagey that OSG users come across, this way users are locked > into a single platform just because of a data type. PSD for example. Sure you can get all these formats with installing other dependencies + compiling some more plugins... >> 2.) it handles live-video > > A quick search on the web suggest that live-video should be possible > under ffmpeg. Really? I thought you need other libs to capture the video footage like libcap, openCV, and feed the stream into ffmpeg to compress it... >> 3.) it handles movies ffmpg can't handle > > Which movie formats are these? If we know which formats are potential > issue we can look them up to see if they are supported/may be > supported in the future. All quicktime-codecs -- there are several codecs handled by quicktime, Sorensen, MotionJpeg, DV, etc. even some lossless codecs. (a list is available at: http://www.apple.com/quicktime/player/specs.html) > ffmpeg isn't a static target, support for various formats is improving > over time so perhaps this issue should becoming less significant. > >> 4.) it has no dependencies on Mac OS X > > Kinda of true, but being only portable to Windows and OSX doesn't make > it a fully portable no strings attached solution. yes I know. One of the keyfeatures of the quicktime-plugin is that you don't need to hassle with all the dependencies - compile the plugin and you'll have most of the image-formats and can play videos. Even distributing the app is simple, because quicktime is part of the system. And with some efforts you'll get double-clickable applications, no need to install needed packages / dependencies on the target systems. I am not a big fan of more external dependencies. For other platforms than unix/linux this is a great hassle to get + install the right packages. There are some package-managers available for OS X (DarwinPorts + Fink for example) but I think most Mac users do not use them. This is why I insist in old deprecated XCode projects which can compile frameworks or the quicktime-plugin, because they help to deliver the os-x experience everybody likes: download an app, copy it to the applications, double-click to run. No installer needed, nada. just my 2 cents :) cheers, Stephan _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
