[gstreamer-bugs] [Bug 385061] Fairly high CPU usage when decoding (~6-15 times slower compared to mplayer)

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=385061

  GStreamer | don't know | Ver: 0.10.3


Jan Schmidt changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1




------- Comment #8 from Jan Schmidt  2006-12-12 20:14 UTC -------
Heh, told you it needed optimising. Even so, I'm surprised at that big a jump.

I'll be suspicious of the ffmpeg based decoder's speed in gst until after I've
compared the sample output to mad and the fluendo decoder's.

I notice in the launchpad report that a few people are find that the Fluendo
mp3 decoder is currently quite slow. That also surprises me..... I expected
people would notice much sooner. 

The plain-C version of Fluendo mp3 decoder is based on the original dist10
sample code (because nothing else had a suitable license), and even though it's
been cleaned up and optimised quite a bit, there's still a long way to go to
truly be a great decoder in that mode (It's open source, please feel free!)

That doesn't apply to the IPP based binary build, which on this machine is
slightly faster than mad.

The decoding in both builds is very accurate though. It produces identical
output to mad to within 1 bit - at least in version 0.10.3 and higher (Ubuntu
should upgrade, 0.10.2 had a nasty distortion bug)

The 0.10.4 flump3dec decoder contains a modest speed boost, on the order of
10%.. still not nearly enough. Really, until it is optimised further, its only
benefit is that it has a patent license.


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email