[gst-devel] GStreamer and libcdio?
rocky at panix.com
Tue Jan 4 05:37:27 CET 2005
Ronald S. Bultje writes:
> What I find surprising is that on the one hand, you insist on not
> duplicating code between projects, but on the other hand, you knowingly
> fork cdparanoia for the, say, 20th time or so, whereas you could also
> link to it and propose to take over maintainership.
I think you are mistaken. Before doing any work on this, I contacted
Monty who gave his blessing on this undertaking. He suggested help in
getting this in on xiph CVS, but since libcdio had a home on GNU and
since he said he probably could not be of much assistance in either
case; therefore it didn't seem all that advantageous and it would have
been a bit of work to move the CVS.
As with vcdimager (where I can now make a release such as I did for
the last one) rather than make some flashy public announcement and
"propose to take over maintainership", I'll work a little on it and
see how it goes. If it goes fine and both I and others are happy with
it, I may move farther on it. But right now, I can't take on whatever
the world's needs are with cdparanoia. And even if it were as simple
as to "propose to take over maintainership", I'm not sure I want to
I'm not aware of the 20 forks you mention, unless you are referring to
what I think are more appropriately called OS "ports". Monty didn't
mention any "forks" except perhaps one which, sadly, is unusable and
both of us (Monty and I) know that, I think. Actually, had that one
been usable, probably libcdio never would have been written in the
first place. If the libcdio/paranoia project moves forward, those that
are sympathetic are welcome to join in. And if there are any ports
that want help using libcdio to reduce their platform dependence I'd
be happy to help them. (There was in fact one *port* that fit into
that category, but I wasn't ready for it at the time; now I am.)
> distribution-provided packages of cdparanoia work fine for us, and the
> cdparanoia plugin (with those packages) works fine for us.
Yes, as I mentioned, I sort of gathered that.
>That's all we care about.
Okay, you are a spokesman for the GStreamer community too!
> If you want to show us how much better libcdio or libvcdinfo is in
> reading data and providing info,
Actually, I'm sorry for having started this. Forgive me for suggesting
GStreamer or a Gstreamer plugin use libcdio or libvcdinfo. I am not
interested in showing you how much better either is. My thought might
have been mutual benefit, but I think I was mistaken here and I
apoplogize. libvcdinfo/libcdio could use help when there is a
deficiency, and I don't sense that would be the case here, as
evidenced by how DVD detection was handled.
> write a GStreamer plugin, submit it for
> inclusion and we'll see how well it performs. If it's good, we might
> prefer it over the currently-used plugins.
I'll put it on the list of things to do. But I have a feeling that
like Bastien's request it's not going to happen soon. And neither of
us will sweat it.
Cool. Like the unconditional: #include <linux/cdrom.h>
I don't see code to handle VCD entries let alone the more
sophisticated things like VCD segments. But then, technically-saavy
you is happy with that -- so I am too.
More information about the gstreamer-devel