typefindfunctions.c and endianness

[Tim Müller]

On Tue, 2016-02-16 at 20:35 +0100, Alex wrote:

Hi Alex,

> I have done some testing with differentversions of gstreamer on
> OpenWRT on an ARM Kirkwood platform.
> There the typefindfunctions fail to detect an MP3 header:
> 
> gst-launch-1.0  filesrc location=file.mp3 ! id3demux ! fakesink -t
> 
> 
> ERROR: from element /GstPipeline:pipeline0/GstID3Demux:id3demux0:
> Could not detect type of contents
> Additional debug info:
> gsttagdemux.c(1417): gst_tag_demux_element_find ():
> /GstPipeline:pipeline0/GstID3Demux:id3demux0
> (snip)
> 
> this goes on some more until there are no more types to compare
> against.
> I already changed the but then I run into problems with
> souphttpsource and mpegaudioparse.
> The actual playback without the typefinding works (locally).
> 
> As I'm not a C programmer at all, I only remember to watch out for
> binary data processing on different architectures (datatype size and
> endianness).
> Is there something that has to be passed to the compiler? (It's not
> just my builds, the OpenWRT buildbot has got the same issue).
> 
> Any help is greatly appreciated (took me some weekends already, to
> come to this conclusion) ;)

Could you file a bug at http://bugzilla.gnome.org and make the file
available somewhere so we can have a look?

This should work on all architectures of course (and mostly does I
think/hope, otherwise I'm sure we'd know about it, mp3 is a fairly
common format after all).

 Cheers
  -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com