ei IOhannes,
thanks you for answers. now it's a bit clear for me.
... personally I will no fight againsts the mess of video API's :)
I can wait until the final GPL video API appear :)
for now I'll just load the videogrid external before Gem.
salut,
ll.
En/na IOhannes zmölnig ha escrit:
lluis gomez i bigorda wrote:
hi all,
yes, we say here "esoteric bug" cause we cannot understand at all why if
Gem is linked against libavifile it beaks our ffmpeg code. videogrid is
not linked against libavifile !!! that's crazy? or not?
not necessarily, since most of those video decoding backends like
ffmpeg, libavifile, gmerlin, quicktime4linux are plugin based and use
each other as backends. so the interrelations between all those are
somewhat messy...
and more, if we load videogrid before Gem the crash desapears. why the
lib load order can change behaviors of a library in that way? maybe some
namespace conflict?
yes. i guess that libavifile comes with an ffmpeg-plugin which will be
initialized on loading and which (due to the way ffmpeg is not released)
conflicts with the ffmpeg version installed on the computer.
anyone can put a bit of light on this please? we are just belivers of
almighty pd wisdom. you know ... :)
a similar problem occured with libstdc++ and ati/radeon drivers a while
ago. i don't think there is a generic solution for such problems (hmm,
on w32 you have to bundle your library with all it's dependencies; maybe
this is the solution;; maybe not)
gfmasdr
IOhannes
_______________________________________________
Pd-dev mailing list
[email protected]
http://lists.puredata.info/listinfo/pd-dev
