[PD-dev] [GEM] evenMORE HOT cvs action!

[Daniel Heckenberg]

On 11/4/03 9:27 AM, "chris clepper" <cclepper at artic.edu> wrote:

>> Zitiere Me <tigital at 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