As of now gstreamer backend hardcodes endianness here :
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.