[gstreamer-bugs] [Bug 377280] [cdiocddasrc] issue if drive endianness != machine endianness

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=377280

  GStreamer | gst-plugins-good | Ver: 0.10.4





------- Comment #4 from rocky at panix.com  2006-11-20 11:09 UTC -------
Yes, libcdio drive endianess reports how the drive gives data back and is not
concerned with the processor that is running the code. (Most drives are little
endian and supposedly all ATAPI/SCSI drives are little endian also.) Look for
example at the source to libcdio's command-line interface, cd-paranoia.c, and
you'll see it has code to swap bytes based on processor behavior. 

If you have libcdio installed, a simple way to determine if libcdio's paranoia
library is reporting the wrong endianness is to use its command-line interface
which is by default installed under the name cd-paranoia. I think the verbose
option will show what it thinks the drive is. If that gets the wrong answer or
cd-paranoia doesn't work without specifying an option, then the problem is in
the libcdio's drive detection. (And if it get's the wrong answer, I'd be
curious to know if there is a Solaris port of cdparanoia which get's the
*right* answer.)

Determinining the drive endianness is based on cdparanoia's hueristic. It
sometimes gets this wrong. And the wrongness could be in an OS-specific part of
the library. That is why both the cdparanoia command-line program and libcdio's
port of this have an option to explicitly specify the drive endianness. 

A plugin should also provide an option or configuration setting for overriding
this too.


(In reply to comment #3)
> > However, I think libcdio should only handle the endianness
> > of CDROM, and should leave gstreamer to handle the endianness of different
> > processor. 
> 
> That's how it works at the moment. GStreamer currently assumes that the data it
> gets from libcdio is in native endianness and the output caps will reflect
> this.
> 
> So either that assumption is generally wrong (couldn't find anything to that
> effect in the docs and haven't seen any complaints from Linux/PPC users yet
> either), or the endianness of the data varies depending on the drive. In the
> first case, we need to fix things in GStreamer's cdiocddasrc element, in the
> second case we need libcdio API to provide us with the information about
> drive/data endianness so we can swap the endianness as appropriate or set the
> correct output caps.
> 


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email