Loïc Minier wrote: > On Sat, Dec 31, 2005, Josh Triplett wrote: >>The attached patch (also temporarily available at >>http://psas.pdx.edu/~josh/gstreamer along with a pre-built deb) >>implements support for the spc plugin in EXTRA_PLUGINS. Note that after >>applying the patch, you need to re-run "./autogen.sh --noconfigure", >>since the patch fixes a bug in configure.ac which led to HAVE_CPU_I386 >>and the other CPU variables not being set. To build the SPC plugin, >>just add "spc" to EXTRA_PLUGINS in debian/rules, run "debian/rules >>maint", and then build the package. >> >>The preferred solution would be to always build the spc plugin, rather >>than only via EXTRA_PLUGINS; however, this patch at least makes it >>relatively easy to create a gstreamer0.8-spc deb. > > FYI, SPC received criticism that it should be built against libspc,
Using a library is a certainly a reasonable idea; two questions: 1) Do you mean "libspc" (which I haven't heard of and can't seem to find) or libopenspc? 2) Anti Resonance's SPC emulator is generally considered the most technically superior, both on the grounds of faithful reproduction and possible enhancement; given that Anti Resonance's code and libopenspc are equally non-portable, I don't think it's worth moving to a library unless that library gives some other advantage. > and > that it might be non-free, That's a more serious concern; however, the code appears to be Freely licensed by upstream. Can you point to any particular issue or concern you have, or that you've seen raised previously? > hence I didn't include it in the first > place. Now it is unmaintained. It is absent from the packages that > are acceptable in the 0.10 series. I did notice that spc didn't seem to be present in 0.10. The biggest problem with the spc plugin at the moment is that it does not read the length information out of the SPC ID666 tag, and thus doesn't know when to stop playing an SPC, so it plays forever until stopped. This needs to be fixed for the SPC plugin to be usable. Other than that one issue (which should be easy to fix for someone who understands gstreamer plugins enough to know how to say when the audio stops; reading out the length field is trivial), the SPC plugin seems like a reasonable item to include. > If you fixed configure.ac by: > -GST_DOC() > +GST_DOCBOOK_CHECK() > > Then this might be worthwhile to send upstream, could you explain how > it break things to call GST_DOC instead of GST_DOCBOOK_CHECK? I > certainly see it is wrong, but I had no problem with it until now. I think it has already been fixed upstream, in newer versions than the one currently in Debian. The issue is that GST_DOC was renamed to GST_DOCBOOK_CHECK, but configure.ac wasn't updated accordingly. This caused the immediately subsequent code to fail, which happened to be the code which checked the target CPU to determine which arch-specific code was acceptable; since SPC needs those target CPU variables set, it fails unless this issue is fixed. Might it be possible to include this EXTRA_PLUGINS support until spc can be sufficiently fixed to be more suitable for building by default? It would make enhancing and testing gstreamer0.8-spc significantly easier. - Josh Triplett
signature.asc
Description: OpenPGP digital signature
