As of now gstreamer backend hardcodes endianness here : http://mxr.mozilla.org/mozilla-central/source/content/media/gstreamer/nsGStreamerReader.cpp#133 On OpenBSD/macppc (big endian) trying to load an mp4 vid it only shows the 'loading' throbber infinitely. Patch in a few to 'fix' it (orthogonal to MOZ_SAMPLE_TYPE_FLOAT32 so a bit of ifdef dance..dunno if the int/48k/16/4321 case makes sense), might not be the best fix but with it i can view some samples on my ppc mac mini.
Created attachment 646110 [details] [diff] [review] set endianness=4321 on BE archs
Alessandro, since this is your code, any comment before i push this commit ?
Looks good, although it can probably be simplified a bit by using G_BYTE_ORDER somehow.
(In reply to Alessandro Decina from comment #3) > Looks good, although it can probably be simplified a bit by using > G_BYTE_ORDER somehow. Right, but since it's a glib macro/#define i'm not sure we're allowed to use it, mxr (http://mxr.mozilla.org/mozilla-central/search?string=G_BYTE_ORDER) only shows an occurence in config/elf-dynstr-gc.c
However, since gstreamer depends on glib we can safely use glib macros there.. i just need to figure out how to get the G_BYTE_ORDER #define properly replaced in the string passed to gst_parse_bin_from_description()
Turns out it's not so simple without resorting to sprintf() games.. chris, any opinion/idea ? is it worth the effort ?
(In reply to Landry Breuil (:gaston) from comment #6) > Turns out it's not so simple without resorting to sprintf() games.. chris, > any opinion/idea ? is it worth the effort ? What you have is fine. We can revisit it with a later patch if you, or someone else, comes up with a better approach.