On 11/4/03 9:27 AM, "chris clepper" cclepper@artic.edu wrote:
Zitiere Me tigital@mac.com:
pix_filmDarwin
- like chris mentioned, this has been improved in the same manner as
pix_filmDarwinYUV, meaning much improved frame access and speed...
great. anyhow, i'd like to move all the OS/lib-dependent film-stuff into film*.cpp files. any objections?
can you explain exactly how the new filmDarwin would be different than pix_filmDarwin? i think i see the usefulness for linux and the many libs required to play various types of files, but the OSX stuff looks exactly the same. maybe we could use ffmpeg for OSX too, but overall the platform dependencies are still there just under different names.
there are two problems here aren't there? - different underlying libraries - different PD message interfaces
given that most of the libraries can be used on most platforms, it would be good to have encapsulated film loading classes. even better would be to make these classes dynamically loadable, so that you wouldn't need to recompile gem to add/remove support for the various libraries. We could also hopefully avoid all the nasty #ifdefs in the code that way too.
I've been trying to work out how best to do this for QuickTime support under windows. It would also be good for pix_filmDarwin to be moved into a filmQuicktime class so that I could then add QTML support for QT for Windows and have it exposed within [pix_film]. Likewise DirectShow codec support for pix_film on windows.
and as i am now doing a workshop with some macers, would it be much of a problem to add an alias from [pix_videoDarwin] to [pix_video] (does this apply to [pix_film] too ?) i think Gem-patches shouldn't be that platform-dependent....
The basic structure of the pix_video code and behaviour doesn't map well to windows video capture APIs... that's why I chose a different set of messages and behaviour for pix_videoDS.
If we're going to consolidate the video capture code, I think we should rework the pix_video messages and behaviour.
Daniel