title: libgstflump3dec.so fail? link: https://onemoretech.wordpress.com/2014/08/11/libgstflump3dec-so-fail/ author: phil2nc description: post_id: 8162 created: 2014/08/11 10:18:38 created_gmt: 2014/08/11 14:18:38 comment_status: closed post_name: libgstflump3dec-so-fail status: publish post_type: post

libgstflump3dec.so fail?

The mp3 decoder that Fluendo ships[1], libgstflump3dec.so, choked on a series of podcast files last night (from my all time favorite, History of English Podcast). Continue reading for another exciting detective story where logic and the scientific method once again come to the rescue. By and large Fluendo's codecs work very well as replacements for their cousins that can be found in gstreamer's "ugly" collection[2]. Last night I was going through a series of mp3 files downloaded from the above-named podcast and found every one of them plagued by some pretty awful stuttering and screechy artifacts. In testing I found the mp3 codec that comes in gstreamer-plugins-ugly[3] was able to handle these particular mp3 encoded files. Also, by transcoding them into the patent-free ogg format I was able to play them without the need for the "ugly" codecs. The key to the discovering the cause of the problem was in the console output of the transcoder (ffmeg) when doing the conversion from mp3 to ogg.

[swscaler @ 0x3ebaf00] deprecated pixel format used, make sure you did set range correctly
[ogg @ 0x3ed0960] Frame rate very high for a muxer not efficiently supporting it.
Please consider specifying a lower framerate, a different muxer or -vsync 2
Output #0, ogg, to 'Ep03-TheIndo-EuropeanFamilyTree.ogg':

Basically what I think this was telling me was that there is a problem with the cover art bundled with the mp3 file (given that the only thing in the file with a "pixel format" would be the artwork). This kind of thing turns out to be an issue for many decoders, including those embedded in hardware. For example, I found this post where the problem was diagnosed as most probably due to the cover art image taking up an excessive amount of space. Album art, as further explained in the thread, is stored in an ID3 tag which is a container at the start of the file consisting of a number of frames. The original purpose of the ID3 tag was to store metadata like the album name, song title, artist name, track number, etc. The specification puts an upper limit on both frame size (16M) and total tag size(256M). The audio engineer quoted in the above-referenced thread advised that artwork image over 600x600 in size could cause this effect [4]. When I opened the file in question with EasyTAG it showed that the image was in fact 600x600, taking up 103M -- way over the 16M individual frame size limit (which would explain ffmpeg's cryptic request that I "make sure you did set range correctly" in relation to the "pixel format" being used for the artwork). From my reading of the thread, it appears that the differences in decoder performance under those conditions can be the result of either one decoder missing "imperfections" like this (in effect simply ignoring the oversized frame). In my case the Fluendo decoder apparently was unable or unwilling to ignore the problem and could not compensate for it. The ugly plugin, on the other hand, like ffmpeg (which in fact continued transcoding despite reporting an error), compensated somehow -- probably by ignoring the offending frame. In the end this doesn't mean that Fluendo's decoder is not as good as the "ugly" one. In fact someone (probably Fluendo's engineers) could argue that the Fluendo code actually did the "right thing" by adhering to standards and not trying to work around the issue. While I might hope that it could have failed more gracefully, it's not hard to understand that the engineers would be loathe to allow the decoder to simply refuse to play the file if it exhibited non-standard composition. [1] This is the version shipped with all of Fluendo's products, currently trading under the "OnePlay" brand, including their free OnePlay MP3 Decoder. [2] The label "ugly" comes from the fact that the the codecs contained in the package may not be legal to distribute or use in certain jurisdictions because no royalties have been paid to patent holders. Read more about the legal issues here and here. [3] According to the documentation the plugin used is libgstmad. The rpmfusion repository ships libgstmad in gstreamer1-plugins-ugly (for gstreamer v1.0) and gstreamer-plugins-ugly (for v0.10). To verify the codec files shipping with a package on Linux distributions using yum, issue the "repoquery -l" command with the name of the target package (e.g. "repoquery -l gstreamer1-plugins-ugly"). [4] Some of the commenters on the thread had what I think were wildly unreasonable expectations regarding the manufacturer's ability to design around this issue. The fact is that the file(s) in question didn't comply with the freaking standard. The whole point in having standards is to provide a predictable environment to code against. Another comment, "It is just ridiculous... that a company aiming to attack the iPod is not able to solve a problem like this via firmware", made me cringe because it showed how little they understood about the inherent limitations of firmware-based systems.

Copyright 2004-2019 Phil Lembo