typefind fails to detect MP3 on ARMv5 (endianness/data type issue?)
Submitted by Alex
Link to original bug (#762224)
Description
Created attachment 321549
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)
Attachment 321549, "debug level 6 on non-working platform":
debug_armv5l.log.gz
Version: 1.x