MPEG-4 support?

> On 10/31/06, Andreas Raab <[hidden email]> wrote:
>> Hi -
>>
>> Brief question: If one would want to integrate MPEG-4 in Croquet/Squeak
>> what would good options look like? Any ideas about available libraries,
>> pain of interfacing those, etc? In the best of all worlds an open source
>> solution would of course be preferable but it would be useful to know
>> and evaluate other alternatives, too.
>
> Apple Quicktime?

> Hi -
>
> Brief question: If one would want to integrate MPEG-4 in
> Croquet/Squeak what would good options look like? Any ideas about
> available libraries, pain of interfacing those, etc? In the best of
> all worlds an open source solution would of course be preferable but
> it would be useful to know and evaluate other alternatives, too.
>
> Cheers,
>   - Andreas
>
>

> Am 31.10.2006 um 03:04 schrieb Andreas Raab:
> > Hi -
> >
> > Brief question: If one would want to integrate MPEG-4 in Croquet/
> > Squeak what would good options look like? Any ideas about available  
> > libraries, pain of interfacing those, etc? In the best of all  
> > worlds an open source solution would of course be preferable but it  
> > would be useful to know and evaluate other alternatives, too.
>
> The mplayer / mencoder stuff is multiplatform (linux, mac, win) and  
> uses libavcodec, ffmpeg etc. and non native codecs. Look at the  
> source or contact the authors. They will support, I guess. Same for  
> the vlc Project.
>
> www.mplayerhq.hu
>
> www.videolan.org
>
> Hope this helps
> Enno

> Hi -
>
> Brief question: If one would want to integrate MPEG-4 in Croquet/Squeak
> what would good options look like? Any ideas about available libraries,
> pain of interfacing those, etc? In the best of all worlds an open source
> solution would of course be preferable but it would be useful to know
> and evaluate other alternatives, too.
>
> Cheers,
>    - Andreas

> Here be licensing dragons, folks, at a minimum when you go from one
> codec to N codecs.
>
> Be very careful on the selection of multimedia codec frameworks, as
> they get you into licensing hades more often than not, and many people
> don't see it coming.
>
> Here's the problem:
>
> You want to plug in a commercial licensed codec into a codec framework,
> to get at a patented algorithm (of which there are many in the media
> area, and software patents cannot, unfortunately, just be ignored,
> despite most of our beliefs the current system is badly broken)  
>
> But the license of the framework's codec interface has terms that
> conflict with the commercial codec's license terms (typically around
> patent issues).
>
> Net result: no legal combination.
>
> This may be ok from an end user's point of view when they put their
> system together out of pieces, as they usually ignore the legal
> problems, but it is a showstopper for re-distributors (e.g. Linux
> distributions, OLPC downstream consumers), who might like/need things to
> work "out of the box" for the end user.
>
> As an example of lack of care about this is the Xine player libraries,
> which would have been perfectly adequate several years before the
> gstreamer library was built.  Gstreamer was explicitly written and care
> taken in its licensing to allow for such combinations to be possible,
> and arguably would not have been necessary had the licensing issue been
> thought through in advance (it was infeasible to get Xine's libraries
> re-licensed, due to the number of contributors).
>
> I have no information about mplayer's licensing situation.
>
> Once burned (actually, free software has been burned multiple times on
> this topic), twice shy.  Please be *very* careful in this area so you
> (and we) don't get burned too.
>                                     Best regards,
>                                        - Jim
>  

> Here be licensing dragons, folks, at a minimum when you go from one
> codec to N codecs.
>
> Be very careful on the selection of multimedia codec frameworks, as
> they get you into licensing hades more often than not, and many people
> don't see it coming.
>
> Here's the problem:
>
> You want to plug in a commercial licensed codec into a codec framework,
> to get at a patented algorithm (of which there are many in the media
> area, and software patents cannot, unfortunately, just be ignored,
> despite most of our beliefs the current system is badly broken)  
>
> But the license of the framework's codec interface has terms that
> conflict with the commercial codec's license terms (typically around
> patent issues).
>
> Net result: no legal combination.
>
> This may be ok from an end user's point of view when they put their
> system together out of pieces, as they usually ignore the legal
> problems, but it is a showstopper for re-distributors (e.g. Linux
> distributions, OLPC downstream consumers), who might like/need things to
> work "out of the box" for the end user.
>
> As an example of lack of care about this is the Xine player libraries,
> which would have been perfectly adequate several years before the
> gstreamer library was built.  Gstreamer was explicitly written and care
> taken in its licensing to allow for such combinations to be possible,
> and arguably would not have been necessary had the licensing issue been
> thought through in advance (it was infeasible to get Xine's libraries
> re-licensed, due to the number of contributors).
>
> I have no information about mplayer's licensing situation.
>
> Once burned (actually, free software has been burned multiple times on
> this topic), twice shy.  Please be *very* careful in this area so you
> (and we) don't get burned too.
>                                     Best regards,
>                                        - Jim
>

> Here be licensing dragons, folks, at a minimum when you go from one
> codec to N codecs.
>
> Be very careful on the selection of multimedia codec frameworks, as
> they get you into licensing hades more often than not, and many people
> don't see it coming.
>
> Here's the problem:
>
> You want to plug in a commercial licensed codec into a codec framework,
> to get at a patented algorithm (of which there are many in the media
> area, and software patents cannot, unfortunately, just be ignored,
> despite most of our beliefs the current system is badly broken)  
>
> But the license of the framework's codec interface has terms that
> conflict with the commercial codec's license terms (typically around
> patent issues).
>
> Net result: no legal combination.
>
> This may be ok from an end user's point of view when they put their
> system together out of pieces, as they usually ignore the legal
> problems, but it is a showstopper for re-distributors (e.g. Linux
> distributions, OLPC downstream consumers), who might like/need things to
> work "out of the box" for the end user.
>
> As an example of lack of care about this is the Xine player libraries,
> which would have been perfectly adequate several years before the
> gstreamer library was built.  Gstreamer was explicitly written and care
> taken in its licensing to allow for such combinations to be possible,
> and arguably would not have been necessary had the licensing issue been
> thought through in advance (it was infeasible to get Xine's libraries
> re-licensed, due to the number of contributors).
>
> I have no information about mplayer's licensing situation.
>
> Once burned (actually, free software has been burned multiple times on
> this topic), twice shy.  Please be *very* careful in this area so you
> (and we) don't get burned too.
>                                     Best regards,
>                                        - Jim
>

> Hi Jim -
>
> Thanks for the pointing out the issues. My current inquiry is actually
> unrelated to OLPC but since there might be some overlap it's useful to
> know these issues. What libraries/frameworks would you recommend using?
> You mention GStreamer, how mature is it?
>
> Thanks,
>    - Andreas
>
> Jim Gettys wrote:
> > Here be licensing dragons, folks, at a minimum when you go from one
> > codec to N codecs.
> >
> > Be very careful on the selection of multimedia codec frameworks, as
> > they get you into licensing hades more often than not, and many people
> > don't see it coming.
> >
> > Here's the problem:
> >
> > You want to plug in a commercial licensed codec into a codec framework,
> > to get at a patented algorithm (of which there are many in the media
> > area, and software patents cannot, unfortunately, just be ignored,
> > despite most of our beliefs the current system is badly broken)  
> >
> > But the license of the framework's codec interface has terms that
> > conflict with the commercial codec's license terms (typically around
> > patent issues).
> >
> > Net result: no legal combination.
> >
> > This may be ok from an end user's point of view when they put their
> > system together out of pieces, as they usually ignore the legal
> > problems, but it is a showstopper for re-distributors (e.g. Linux
> > distributions, OLPC downstream consumers), who might like/need things to
> > work "out of the box" for the end user.
> >
> > As an example of lack of care about this is the Xine player libraries,
> > which would have been perfectly adequate several years before the
> > gstreamer library was built.  Gstreamer was explicitly written and care
> > taken in its licensing to allow for such combinations to be possible,
> > and arguably would not have been necessary had the licensing issue been
> > thought through in advance (it was infeasible to get Xine's libraries
> > re-licensed, due to the number of contributors).
> >
> > I have no information about mplayer's licensing situation.
> >
> > Once burned (actually, free software has been burned multiple times on
> > this topic), twice shy.  Please be *very* careful in this area so you
> > (and we) don't get burned too.
> >                                     Best regards,
> >                                        - Jim
> >
>