Through the labors of August and some contributions from Luke and me, there are now libgavl1 and gmerlin-avdecoder1 for Fink. We are working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin- avdecoder? I think it'll have much better codec support than Quicktime.
Check out all of the codec libs that are included. These will all then automatically be included in Pd-extended:
.hc
----------------------------------------------------------------------------
¡El pueblo unido jamás será vencido!
Hans-Christoph Steiner wrote:
Through the labors of August and some contributions from Luke and me, there are now libgavl1 and gmerlin-avdecoder1 for Fink. We are working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin-avdecoder? I think it'll have much better codec support than Quicktime.
how not to? which complications do you expect?
Check out all of the codec libs that are included.
obviously these is exactly not the point of having a plugin-architecture...
These will all then automatically be included in Pd-extended:
thanks for your efforts.
gmasdr IOhannes
On May 3, 2009, at 11:34 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
Through the labors of August and some contributions from Luke and me, there are now libgavl1 and gmerlin-avdecoder1 for Fink. We are working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin-avdecoder? I think it'll have much better codec support than Quicktime.
how not to?
I don't understand.
which complications do you expect?
Hmm, I don't really know enough to say. August and I have been working quite a bit on getting this whole thing building in Fink and now MinGW. I think then Gem, Gridflow, PDP, etc. can all use this single framework for AV IO on all platforms, or at least GNU/Linux and Mac OS X.
Check out all of the codec libs that are included.
obviously these is exactly not the point of having a plugin- architecture...
I don't understand. not?
.hc
These will all then automatically be included in Pd-extended:
thanks for your efforts.
gmasdr IOhannes
----------------------------------------------------------------------------
"[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.
hi.
sorry for the overcryptic mail...
Hans-Christoph Steiner wrote:
working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin-avdecoder? I think it'll have much better codec support than Quicktime.
how not to?
I don't understand.
Gem uses configure to detect which libraries are available on the build system. at least it does so on the autobuild machines.
since the configury is usually greedy, it will take conscious effort to disable a certain feature (e.g. the use of gavl/gmerlin once it is detected)
which complications do you expect?
of course the above is not entirely true (there are a few hacks in the configury to avoid groups of libraries which are known to cause problems: e.g. ImageMagick will automatically disable libtiff).
there might as well be special hacks that disable the use of the more modular "new" (though quite aged by now) approach of film-loading.
i know that there _are_ such special hacks, i just don't know whether they effect the film-business (without looking at the code)
Hmm, I don't really know enough to say. August and I have been working quite a bit on getting this whole thing building in Fink and now MinGW. I think then Gem, Gridflow, PDP, etc. can all use this single framework for AV IO on all platforms, or at least GNU/Linux and Mac OS X.
which is great (esp. as Gem should already be there :-))
Check out all of the codec libs that are included.
obviously these is exactly not the point of having a plugin-architecture...
I don't understand. not?
that was the unneccessary harsh part of my mail. however, let me explain: plugins (as used e.g. by gmerlin) are used to create a flexible bridge between two "applications"; if the code-base of appA changes, then appB does not need to know anything about this change; if appA is totally unavailable, most functionality of appB will be untouched (e.g. Gem can be seen as a bridge between openGL and Pd; openGL doesn't know nor care which Pd version we have; nor the other way round; it's part of Gem's task to track any incompatible changes in either of them; if openGL is entirely missing on a system, this doesn't affect Pd as a whole; it will make Gem unusable, but you can still play nicely with Pd)
this is even more true with decoder-plugins: if the Sorenson2000 codec is missing on my system, i still might be able to decode motion jpeg videos; my application should continue to work even without any plugins installed. if i need a special codec not installed on my system, my task should be to install the missing codec and not to update my application. (now , that's an important statement here)
obviously, to make a platform to work with in a reasonable way, an application might choose to ship with some plugins. (and i think that is your point here)
what i mainly wanted to oppose with my rant was, that by embracing gmerlin/gavl in the way it is done know (that is: fully including the source into PdX), you are giving away to good things about it. in one of my former mails i have written: "the ffmpeg-nightmare is delegated to a single-point: gavl". by including the sources of gavl/gmerlin, the near impossible task of tracking changes of ffmpeg is back with us: whenever ffmpeg changes sufficiently (that is: each other week), gmerlin will have to adopt. then we will have to import the new gavl sources, in order to support the new ffmpeg version.
otoh, having a stable API in gavl/gmerlin enables us to just link against gmerlinj/gavl "once", and ship (with) "a" decoder-plugin for ffmpeg, and once this is outdated, the decoder-plugin could be updated, rather than the entire PdX. and less dependencies to wait for.
all in all, my point about plugins is that they are plugins, thus externally loadable and updateable pieces. the sole idea of plugins lies within this externality. (else we could just statically link everything in)
i guess your point about pugins is, that they are totally useless unless you have them. (else we could talk about black holes and whatelse, with an equal impact on Pd)
like always, we are both right.
famsf IOhannes
On May 5, 2009, at 4:02 AM, IOhannes m zmoelnig wrote:
hi.
sorry for the overcryptic mail...
Hans-Christoph Steiner wrote:
working on getting readanysf~ compiling nicely. Now that leads me to wonder: how about getting Gem on Mac OS X to use gavl and gmerlin-avdecoder? I think it'll have much better codec support than Quicktime.
how not to?
I don't understand.
Gem uses configure to detect which libraries are available on the build system. at least it does so on the autobuild machines.
since the configury is usually greedy, it will take conscious effort to disable a certain feature (e.g. the use of gavl/gmerlin once it is detected)
which complications do you expect?
of course the above is not entirely true (there are a few hacks in the configury to avoid groups of libraries which are known to cause problems: e.g. ImageMagick will automatically disable libtiff).
there might as well be special hacks that disable the use of the more modular "new" (though quite aged by now) approach of film- loading.
i know that there _are_ such special hacks, i just don't know whether they effect the film-business (without looking at the code)
For Pd-extended, we should not rely on automatic detection, since it is really a packaging question. When packaging, the standard practice from what I've seen is to disable all automatic detection and explicitly tell configure what it should be finding. For example, this is what we did in the Fink package for gmerlin-decoder:
./configure --prefix=/sw --disable-gmerlin --enable-libavcodec -- enable-libpostproc --enable-libswscale --enable-libavformat --enable- theora --enable-speex --disable-mjpegtools --enable-vorbis --disable- libmpeg2 --enable-libtiff --enable-openjpeg --disable-samba --enable- libpng --enable-faad2 --enable-dvdread --enable-flac --enable-musepack --enable-mad --enable-liba52 --enable-libdca --enable-libcdio -- disable-win32 --with-avcodec=%p --with-avformat=%p --with-vorbis=%p -- with-faad2-prefix=%p
So ffmpeg, gavl, and gmerlin-decoder are now installed on all the Mac OS X build machines, so I think it would be good to give a similar treatment to the Gem options for Mac. Any suggestions? You could just commit them directly, its in packages/Makefile.
Hmm, I don't really know enough to say. August and I have been working quite a bit on getting this whole thing building in Fink and now MinGW. I think then Gem, Gridflow, PDP, etc. can all use this single framework for AV IO on all platforms, or at least GNU/ Linux and Mac OS X.
which is great (esp. as Gem should already be there :-))
Check out all of the codec libs that are included.
obviously these is exactly not the point of having a plugin- architecture...
I don't understand. not?
that was the unneccessary harsh part of my mail. however, let me explain: plugins (as used e.g. by gmerlin) are used to create a flexible bridge between two "applications"; if the code-base of appA changes, then appB does not need to know anything about this change; if appA is totally unavailable, most functionality of appB will be untouched (e.g. Gem can be seen as a bridge between openGL and Pd; openGL doesn't know nor care which Pd version we have; nor the other way round; it's part of Gem's task to track any incompatible changes in either of them; if openGL is entirely missing on a system, this doesn't affect Pd as a whole; it will make Gem unusable, but you can still play nicely with Pd)
this is even more true with decoder-plugins: if the Sorenson2000 codec is missing on my system, i still might be able to decode motion jpeg videos; my application should continue to work even without any plugins installed. if i need a special codec not installed on my system, my task should be to install the missing codec and not to update my application. (now , that's an important statement here)
obviously, to make a platform to work with in a reasonable way, an application might choose to ship with some plugins. (and i think that is your point here)
what i mainly wanted to oppose with my rant was, that by embracing gmerlin/gavl in the way it is done know (that is: fully including the source into PdX), you are giving away to good things about it. in one of my former mails i have written: "the ffmpeg-nightmare is delegated to a single-point: gavl". by including the sources of gavl/gmerlin, the near impossible task of tracking changes of ffmpeg is back with us: whenever ffmpeg changes sufficiently (that is: each other week), gmerlin will have to adopt. then we will have to import the new gavl sources, in order to support the new ffmpeg version.
otoh, having a stable API in gavl/gmerlin enables us to just link against gmerlinj/gavl "once", and ship (with) "a" decoder-plugin for ffmpeg, and once this is outdated, the decoder-plugin could be updated, rather than the entire PdX. and less dependencies to wait for.
all in all, my point about plugins is that they are plugins, thus externally loadable and updateable pieces. the sole idea of plugins lies within this externality. (else we could just statically link everything in)
i guess your point about pugins is, that they are totally useless unless you have them. (else we could talk about black holes and whatelse, with an equal impact on Pd)
like always, we are both right.
On Mac OS X, the ffmpeg, gavl, gmerlin, etc. stuff is all shipped as dylibs in Pd-extended.app/Contents/lib, just like VLC does it. OSX is crippled as compared to Debian with package management, so this turns out to be the best way to manage this stuff. If you want, you could swap out those dylibs with newer versions for the 'plugin'-ability.
Windows is a about the same, so the idea with the Pd-extended installer is that it installs the DLLs for the codecs.
The tricky question for now is on Debian/Ubuntu. gmerlin-decoder is not in Debian or Ubuntu.
.hc
----------------------------------------------------------------------------
-
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig