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