[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