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
On 10/31/06, Andreas Raab andreas.raab@gmx.de 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? Squeak code at: http://home.comcast.net/~zurgle/quicktim.htm Apple API docs at http://developer.apple.com/documentation/QuickTime/
Chris
Chris Barham schrieb:
On 10/31/06, Andreas Raab andreas.raab@gmx.de 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?
What about Linux users? Are there open source MPEG-4 implementations? (I don't have the time now to check, need to go to work, but probably folks here just know about some package).
Cheers, Hans-Martin
Hello Hans-Martin,
Tuesday, October 31, 2006, 12:30:20 AM, you wrote:
HMM> Are there open source MPEG-4 implementations? (I don't have the HMM> time now to check, need to go to work, but probably folks here HMM> just know about some package).
DivX offers generic decompression of mpeg-4, and DivX is the more commercial sibling of xvid. Therefore, I wonder if xvid offers generic mpeg-4 decompression as well. Doesn't xvid come with a reasonable license? (I don't know)
Andreas Raab skrev:
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
www.videolan.org is a pretty good gpl player that play mpeg4.
Karl
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!
Enno Schwass onkelenno@mac.com wrote:
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
Adding more info, yes, AFAIK MPlayer and Videolan are the two cross platform main "player" applications/projects out there that have very good support for MPEG-4 (which is a very wide area of standard: http://en.wikipedia.org/wiki/MPEG4) and lots more.
The movies from OOPSLA were encoded using mencoder (a part of MPlayer to do command line encoding) btw, 2-pass using the XviD codec:
http://en.wikipedia.org/wiki/Xvid http://www.xvid.org
...which is one of the MPEG-4 codecs (and compatible with Divx - the commercial sibling). The best MPEG-4 codec that keeps getting mentioned (but haven't used myself) is the implementation of MPEG-4 part 10 (called H.264: http://en.wikipedia.org/wiki/H.264) called x264:
http://www.videolan.org/x264.html http://en.wikipedia.org/wiki/X264
And the two players mentioned above can AFAIK use XviD, x264, libavcodec (a whole library of codecs) and many more.
But anyway, I presume you want to hook into the most promising player in order to be as future proof as possible - and Videolan comes to mind given its stronger focus on cross platformness (just my feeling).
regards, Göran
Andreas Raab puso en su mail :
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
Sure you know this link
I using the OS X port, I copy from the software
ffmpegX is a software interface providing a graphical way of operating existing, third-party Unix tools listed hereafter, without needing to type command lines in terminal. Graphical controls are sent programmatically to such external components developed by third parties and running outside the ffmpegX application.
And I say is more powerful what QuickTime.
Edgar
__________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
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
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
Thanks Jim. Do you have recommendations on what to do?
brad
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
Gstreamer was deliberately written to avoid these problems: net result is that you can use a legal, paid up MP3 binary codec (for which the source is also available) from Fluendo (though you still have to deal with signing paper with Fluendo to redistribute, according to Fraunhofer's license). It is LGPL, with some sort of exception worked out, that I didn't find in cursory exampination.
Real's Helix framework is probably also on sound legal footing, but has little uptake it the open source and free software community. I haven't checked it's terms.
We're using gstreamer on the OLPC system. Regards, - Jim
On Tue, 2006-10-31 at 10:50 -0800, Andreas Raab wrote:
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
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andres Valloud -
Brad Fuller -
Chris Barham -
Edgar J. De Cleene -
Enno Schwass -
goran＠krampe.se -
Hans-Martin Mosner -
Jim Gettys -
karl