You want to use plugins, sure go ahead, I want to use smalltalk, sure go
ahead. If we develop a framework correctly that lets us mix and match, why
not do it that way?
You want to have support for MPEG2 and 4 and theora? Great! So do I, but I
think you are missing the point that there will be a LARGE number of simple
codecs. A lot of these already have most if not all of their code in Squeak
which can be re-used and/or ported to a new framework so that we have
consistency.
This framework will allow you to use FFI or Plugins or Smalltalk or some new
technique. Your class can have as much functionality as you want and as long
as it conforms to the minimum spec, it will auto magically work with any of
the tools. 
These simple codecs become the core, platform independent set of media types
we distribute in Base.
External libraries are great and make perfect sense not having to reinvent
the wheel but they also have major limitations. As an example, can you play
an MP3 using the Squeak classes from a Squeak socket? I know I could with
the OGG library because it wanted data from a FILE structure. I am sure
there is some tricky way to do that but I was easier for me to re-write it
in Smalltalk than cobble together some badly integrated solution.

The problem with trying to do the containers now is that there are so many
exceptions because of the haphazard way the code has evolved.
GUIs are great except when there isn't a consensus on how the data is
presented which is the situation now. Try to write a tool that plays any
audio type in Squeak from a URI, very tricky at the moment :)

So to recap so people don't get the wrong idea. I don't have a problem with
plugins/external libraries. They are necessary for some codecs but there are
Lots of others where a plugin is overkill. You might as well just write
everything in "C" ;)

I know it is boring but getting the base stuff sorted (as much as we can at
the moment) means lots less effort later. Oh and it means that there is at
least one set of tests that works for every codec. That saves LOTS of time
;)


> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-
> bounces at lists.squeakfoundation.org] On Behalf Of Martin Kuball
> Sent: Monday, 21 February 2005 4:31 AM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: Re: Improving Squeak's Mutlimedia
> 
> Am Sunday 20 February 2005 02:10 schrieb Russell Penney:
> >
> > Now one of my biggest concerns is that we should try to develop
> > EVERYTHING in Squeak with as few plugins as possible. I wrote the
> > OGG decoder in "pure" Smalltalk so it is possible. Of course by
> > converting a small part of the decoder to a plugin I sped
> > everything up 10 fold but that came later ;)
> >
> > I think this is important to remove platform dependencies or
> > dependencies on external libraries. We may end up using them purely
> > for performance but I think we should have a goal of not using them
> > in the first part.
> 
> I don't share your point of view here. Writing codecs in pure
> smalltalk is interesting and may teach you a lot. But I don't think
> we have the manpower to do this. I want to have support for mpeg2,
> mpeg4 (xvid, divx), theora, etc, and windows people may want to use
> the microsoft codecs. Do you want to implement all this again - if it
> were possible at all. And I think the speed of a codec is very
> important. Every cpu cycle counts.
> 
> I would like to have small Class for each codec that uses the
> FFIPlugin as interface to the external library. This way everybody
> with a basic knowledge of his favourite codecs API could integrate it
> integrate it in no time.
> 
> We should concentrate on the container stuff and nice guis to
> manipulate the basic multimeda entities. This is work enough for the
> next month.
> 
> Martin
> 
>