Bug#345489: [PATCH] Add support for spc plugin in EXTRA_PLUGINS

[Josh Triplett]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gstreamer-maintainers/attachments/20060108/f004d7c1/signature-0001.pgp