After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 130050 - divx/xvid crash gst-register
divx/xvid crash gst-register
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal major
: 0.7.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2003-12-26 20:37 UTC by Ronald Bultje
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ronald Bultje 2003-12-26 20:37:34 UTC
XviD/DivX apparently share several public symbols ("grep divx
/usr/lib/libxvidcore.so" to see for yourself). gst-register loads and
unloads each plugins. Unloading is apparently unimplemented. Therefore,
xvid will overrule the divx symbols before divx can load itself, or divx
will load symbols which xvid wants to overrule. The one makes the other crash.

xvid will segfault in xvid_init() if divx was loaded first. divx versions
etc. will be overrules by xvid and the version check in the divx plugin
(because divx4linux isn't ABI/API stable) therefore fails if xvid was
loaded before divx, and the plugin fails to load.

I don't know how to solve it, apart from kicking the hell out of the xvid
people for screwing up so badly (they overrule divx symbols, but not the
other way around). Anyone knows a better (working ;) ) solution for this
issue? Even if we'd implement plugin unloading, we still wouldn't be able
to load xvid/divx plugins in the same pipeline. :(.
Comment 1 Ronald Bultje 2004-01-03 19:40:36 UTC
Fixed in HEAD/CVS. Latest beta3 of xvid runs fine with divx, even in
the same pipeline.