[gst-devel] GStreamer and libcdio?

[R. Bernstein]

Hi - 
Ronald S. Bultje writes:
 > Hi,
 > 
 > [ I meant, put the code to link to libcdio in Totem, not put the whole
 > libcdio codebase in totem... ;) ]

[ I'm sorry I wasn't clear - for xine, totem pretty much *has* to link
the libcdio codebase and if gstreamer plugins did, then I guess totem
would pretty much have to do that too ;) ]

 > Totem uses whatever the backend provides.  GStreamer does not depend on
 > GNOME, but uses elements that may link to external libs. Cdparanoia for
 > CDDA, libdvdread/libdvdnav for DVDs and we have our own VCD/SVCD reader
 > element (vcdsrc).

Ah. Okay now we're getting to the crux of the situtation. Why might
one use libcdio/vcdimager in gstreamer plugins?

cdparanoia: 

The official cdparanoia sources from Monty are for GNU/Linux
only. There hasn't been any active development in something like 4
years.  Because cdparanoia is so useful, it has been patched to work
on many (most?) other OSs. But not surprisingly, all of the OS ports
are pretty much uncoordinated: unique patches off the source and no 
doubt there is some commonality between the patches.

cdparanoia could be useful even for non-audio mode situations, because
what it is trying to detect is speed skew. Although mode1 and mode2
have their own error correction, if I understand correctly, you might
get even better results by first detecting the skew and then applying
the sector-based error correction (in software) on top of that.

The next release of libcdio will have cdparanoia built in. It could
provide a more unified framework for extending skew correction in
other CD reading modes, since libcdio does support these non-audio
disc-reading modes. (cdparanoia doesn't). There is an affinity
between libcdio and vcdimager (which as of a couple years requires
libcdio). libcdio can borrow from vcdimager with help on handling the
software error correction since vcdimager already understands at least
in the encoding direction.

Having written this though, perhaps this is too early for libcdio in
gstreamer. As you say, you have something that works and clearly
things like CD-Text and CD disk image support aren't of concern. (CD
disk image support is most useful in authoring applications for
testing before burning). If users need/want any of these, there's
always xine (via libcdio) or vlc or something else. Or players can
link libcdio in addition to cdparanoia libraries. I've come to learn
that at least in the media-player projects, code bloat and creating or
contributing to a common library isn't all that important, especially
if you can just hack in what you want in your own pet project. Okay,
so a cut and paste on an update is missing here, but it's not all that
important anyway. ;-) Why else do so many projects which deal with
CD-DA have their own CDDB code when a perfectly usable if not better
CDDB library exists?

VCD/SVCD reader element:

Interesting. I don't see this in CVS right now. How well does vcdsrc
handle playing MPEGs in the ISO 9660 track? It handles still frames,
numbered menu selections, and multi-default selections, right?

One can get at all of these things right now in the xine VCD plugin
because it uses libvcdinfo. In videolan's vlc, it's all there too via
libvcdinfo; we just haven't figured out how to get the vlc part
cooperating fully.

libdvdread/libdvdnav for DVDs: 

Not much to say here, but I note that since these libraries predate
libcdio, the "brokenness" asserted for libcdio applies to
libdvdread/libdvdnav as well. (I haven't checked to see if "bug"
report was filed here too. ;-)