GNOME Bugzilla – Bug 571116
Make liboil optional in all gstreamer modules
Last modified: 2010-11-01 17:30:16 UTC
The following patches (to -base, -good, -ugly, and -bad), make liboil optional. They add a --disable-liboil configure argument, and implement it. Note that, with liboil disabled, certain optimisations are turned off. Rationale: liboil is difficult to build and is not being actively maintained. It usefully supports only one compiler (gcc). Building liboil with another compiler (e.g. MSVC) produces a liboil that is not useful for optimisation purposes. What do people think of this?
Created attachment 128342 [details] [review] Make liboil optional in -base
Created attachment 128343 [details] [review] Make liboil optional in -good
Created attachment 128344 [details] [review] Make liboil optional in -ugly
Created attachment 128345 [details] [review] Make liboil optional in -bad
IMHO a good idea but then at least deinterlace2 will be almost unusable slow because no assembly optimizations are used. We should get the hardware feature detection into some gstreamer library then I guess... Are you sure David doesn't maintain liboil anymore? Does he spent all his efforts nowadays on ORC and Dirac?
liboil isn't entirely unmaintained. It's not being particularly actively developed though, which is mostly what I meant. Getting back some of these things (e.g. cpu feature detection) some other way would be nice, but doesn't need to be a prerequisite for this - I'd expect most users of gstreamer to continue to use liboil (it'd default to on).
Liboil is maintained, and occasionally developed. However, liboil isn't likely to work better with MSVC any time in the near future. Orc should work fine with MSVC, but Orc is essentially vaporware. At some point, I had intended to provide a "liboil-lite" that compiled only the reference functions and could be easily cropped down for embedded use. In this case, "embedded" means "embedded into Songbird". It's a little silly for Songbird to pull in all of liboil if it only uses a few functions and doesn't even compile optimized versions. I'm not opposed to this, but I think it could accomplished as effectively with the liboil-lite concept.
> Orc should work fine with MSVC, but Orc is essentially vaporware. > > (...) > > At some point, I had intended to provide a "liboil-lite" that compiled only the > reference functions and could be easily cropped down for embedded use. In this > case, "embedded" means "embedded into Songbird". It's a little silly for > Songbird to pull in all of liboil if it only uses a few functions and doesn't > even compile optimized versions. > > I'm not opposed to this, but I think it could accomplished as effectively with > the liboil-lite concept. Can this bug be closed? Or does anyone still want to pursue some kind of orc-lite approach (e.g. have orc output assembly for a certain target and use that instead of the C backup code, or something)?
"orc-lite" would be a orc feature request, not a gstreamer bug.