GNOME Bugzilla – Bug 762224
typefind fails to detect MP3 on ARMv5 (endianness/data type issue?)
Last modified: 2018-11-03 11:44:58 UTC
Created attachment 321549 [details] debug level 6 on non-working platform On OpenWRT stable build (Chaos Calmer 15.05) with "stock" packages gstreamer-1.4.5 as well as self-compiled v1.2.4 and v1.7.1 an error occurs when typefind fails to determine the type of any MP3 file: wget -O test.mp3 "http://soundbible.com/grab.php?id=1815&type=mp3" gst-launch-1.0 filesrc location=test.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 Running the same on any other architecture (I have ppc and mips) using the same OpenWRT package FOUND TAG : found by element "fakesink0". encoded by: dBpoweramp Release 13.5 container format: ID3 tag My cpuinfo: model name : Feroceon 88FR131 rev 1 (v5l) BogoMIPS : 1191.11 Features : swp half fastmult edsp CPU implementer : 0x56 CPU architecture: 5TE CPU variant : 0x2 CPU part : 0x131 CPU revision : 1 Hardware : Marvell Kirkwood (Flattened Device Tree) To reproduce the following OpenWRT packages (and their dependencies) are required: gstreamer1-utils gst1-mod-typefindfunctions gst1-mod-id3demux In order to find a fix I modified gsttypefindfuntions.c GST_MP3_TYPEFIND_TRY_HEADERS (2) which worked for this particular testfile. Unfortunately mpegaudioparse was not able to determine nor channels nor bitrate afterwards which results in stuttering audio while streaming. Bypassing any caps detection actually plays the mp3 (but that's no option since I want to use playbin eventually) gst-launch --gst-disable-registry-update --gst-disable-registry-fork filesrc location=test.mp3 ! mad ! alsasink (the registry fork gave me a Segfault, but that's probably unrelated)
It doesn't look like there's an opportunity for an endianness issue here, if PPC works (big endian) and little endian (x86, etc). The debug log looks a bit suspicious around the MP3 type finder, not sure how it can even get into that succession of events there. My best guess for now would be that this is something compiler related. But someone who can reproduce this issue would have to step through the MP3 typefinding function and see where things go wrong.
Sorry for being imprecise, my ppc device runs on Debian Wheezy - it probably should not have been added to the comparison. I could offer ssh access to a device or even ship one to a party willing to debug (preferably within Germany).
I have a powerbook with Debian I can try this on.
The PPC one works, it's the ARMv5 (little endian then I guess) that fails. My best guess here is still something fishy with the compiler but someone would need to look :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/254.