[gstreamer-bugs] [Bug 377280] [cdiocddasrc] issue if drive endianness != machine endianness
GStreamer (bugzilla.gnome.org)
bugzilla-daemon at bugzilla.gnome.org
Wed Nov 22 02:30:59 PST 2006
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 #14 from rocky at panix.com 2006-11-22 10:29 UTC -------
Chris Wang wrote in Comment #13
I agree that most of CD-DA plugin doing the byte swapping o the layer above
CD
read,
I don't know who you are agreeing with, but that's *not* what I wrote.
CD read should take case of the byte sex of CPU which xine and vlc do.
I believe both xine and vlc and other media players *don't* do any byte
swapping in when *not* using cdparanoia. I don't see this code in any CD-DA
"access" module of vlc or any CD-DA "input" plugin for xine.
Try this test and report back the results Take an audio CD and run the
"cd-read" program from libcdio using the option --mode=audio. Do this on both
the Solaris computer you are having problems with (a little endian drive on a
big endian CPU) and some other computer that has a little endian drive on a
little endian CPU. If you get results like I just did, you'll see you get the
*same* data, possibly shifted by some sort of offset. There is no byte swapping
going on in the way the data is getting passed back from the CD-ROM.
What I said was that if the data gets passed back via a cdparanoia read --
libcdio or not -- you will have to take into account the byte sex of the CPU.
--
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email
More information about the Gstreamer-bugs
mailing list