Hello list!
pdvjtools users detected a trouble in videogrid external with pd-extended 0.42.5 and ubuntu karmic.
The initial problem was when we add a video into the videogrid then pd crash.
We tested with 0.41.4 and all is fine, no problem exists.
After debuggin the code, we found some esoteric libavifile relation with this crash.
Facts ::
1.- If you install pd-extended 0.42.5 in a ubuntu karmic and try to load a video in the videogrid-help path pd will crash.
2.- If you remove pd-extended and libavifile, then force install pd-extended 0.42.5 (without libavfile installed), videogrid runs well. no crash at all.
3 .- Back to a normal pd-extended installation (with libavifile). As Gem is the only library linked against libavifile in pd-extended we'd tryed to load videogrid before Gem and it agains worked well without any crash.
4.- Loading Gem before videogrid is the same as 1. pd crashes when loads a video on videogrid.
So it seems avifile library but we don't know exactly why if we don't link our library with libavifile.
Hope to be helpfull and thanks for read ;)
Lluis & Sergi.
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?
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?
anyone can put a bit of light on this please? we are just belivers of almighty pd wisdom. you know ... :)
thanks in advance, ll.
En/na slario@gmail.com ha escrit:
Hello list!
pdvjtools users detected a trouble in videogrid external with pd-extended 0.42.5 and ubuntu karmic.
The initial problem was when we add a video into the videogrid then pd crash.
We tested with 0.41.4 and all is fine, no problem exists.
After debuggin the code, we found some esoteric libavifile relation with this crash.
Facts ::
1.- If you install pd-extended 0.42.5 in a ubuntu karmic and try to load a video in the videogrid-help path pd will crash.
2.- If you remove pd-extended and libavifile, then force install pd-extended 0.42.5 (without libavfile installed), videogrid runs well. no crash at all.
3 .- Back to a normal pd-extended installation (with libavifile). As Gem is the only library linked against libavifile in pd-extended we'd tryed to load videogrid before Gem and it agains worked well without any crash.
4.- Loading Gem before videogrid is the same as 1. pd crashes when loads a video on videogrid.
So it seems avifile library but we don't know exactly why if we don't link our library with libavifile.
Hope to be helpfull and thanks for read ;)
Lluis & Sergi.
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
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
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
-
IOhannes zmölnig -
lluis gomez i bigorda -
slario＠gmail.com