typefindfunctions.c and endianness

[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


GST_PLUGIN_LOADING gstpluginfeature.c:115:gst_plugin_feature_load: loaded plugin typefindfunctions
          default gsttypefindhelper.c:98:helper_find_peek:<sink:proxypad0> 'audio/mpeg' called peek (0, 2048)
typefindfunctions gsttypefindfunctions.c:1278:mp3_type_frame_length_from_header: mp3typefind: calculated mp3 frame length of 313 bytes
typefindfunctions gsttypefindfunctions.c:1281:mp3_type_frame_length_from_header: mp3typefind: samplerate = 44100 - bitrate = 96 - layer = 3 - version = 3 - channels = 2
typefindfunctions gsttypefindfunctions.c:1405:mp3_type_find_at_offset: found 1. header at offset 0 (0x0)
typefindfunctions gsttypefindfunctions.c:1278:mp3_type_frame_length_from_header: mp3typefind: calculated mp3 frame length of 314 bytes
typefindfunctions gsttypefindfunctions.c:1281:mp3_type_frame_length_from_header: mp3typefind: samplerate = 44100 - bitrate = 96 - layer = 3 - version = 3 - channels = 1
typefindfunctions gsttypefindfunctions.c:1405:mp3_type_find_at_offset: found 2. header at offset 313 (0x139)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 3. header at offset 627 (0x273) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 40 (0x28) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 41 (0x29) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 132 (0x84) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 133 (0x85) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 134 (0x86) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1385:mp3_type_find_at_offset: 1. header at offset 135 (0x87) was not an mp3 header (possibly-free: no)
typefindfunctions gsttypefindfunctions.c:1278:mp3_type_frame_length_from_header: mp3typefind: calculated mp3 frame length of 276 bytes
typefindfunctions gsttypefindfunctions.c:1281:mp3_type_frame_length_from_header: mp3typefind: samplerate = 44100 - bitrate = 256 - layer = 1 - version = 3 - channels = 2
typefindfunctions gsttypefindfunctions.c:1405:mp3_type_find_at_offset: found 1. header at offset 213 (0xD5)


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) ;)