[gst-devel] gst-ffmpeg & decodebin

Tom Cooksey thomas.cooksey at trolltech.com
Wed Feb 6 18:35:12 CET 2008


On Wednesday 06 February 2008 15:42:04 Michael Smith wrote:
> On Wed, 2008-02-06 at 16:33 +0100, Tom Cooksey wrote:
> > Hi,
> >
> > Background: I am trying to get the new Qt/KDE Phonon library working on
> > Qtopia Core (Qt/Embedded). Linux/Qtopia Core uses the GStreamer backend
> > for Phonon - specifically the decodebin element.
> >
> > I'm having problems getting decodebin (& playbin) to detect & use the
> > ffmpeg elements. E.g.
> >
> > The following works fine:
> > gst-launch filesrc location=01_Neighborhood_1_Tunnels_.mp3  ! ffdemux_mp3
> > ! ffdec_mp3 ! alsasink
> >
> > However, using decodebin I get:
> >
> > $ gst-launch-0.10 filesrc location=01_Neighborhood_1_Tunnels_.mp3 !
> > decodebin ! audioconvert ! alsasink
>
> The key difference between these two is that decodebin will only
> autoplug elements that have a non-zero rank.
>
> ffdemux_mp3 and ffdec_mp3 have zero rank, because they don't work
> properly and there are better ones available in gstreamer. So they're
> there, and you can explicitly use them if you want, but we strongly
> recommend against it.

But surely the ffmpeg plugins should be used if there are no other plugins 
avaliable? Can they not just be given a very low (non-zero) rank, so if 
there's _anything_ else which will play them, it will be used and if there 
isn't, ffmpeg is used as a last resort?

Is it just ffdemux_mp3 & ffdec_mp3 which have a rank of zero? Do any of the 
other ffmpeg demuxers & decoders have a higher rank (BTW: where is this 
defined? in gst-ffmpeg or decidebin)? If all ffmpeg elements are given a 
zero-rank, gst-ffmpeg effectivly becomes useless for our purposes and we 
loose all the codecs it supports which aren't covered by other gstreamer 
plugins (any idea how big the gap is here?).

Another issue is performance. I've tested cpu usage (with top - not very 
scientific I know), and the ffmpeg plugin seems to perform better than even 
mad (~23% CPU for mad, ~20-21% for ffmpeg on a 266Mhz armv4). For this 
reason, I personally prefer the ffmpeg decoder. When you say "they don't work 
properly and there are better ones available in gstreamer", what exactly do 
you mean? Are there build issues, runtime crashes, compatability problems, 
performance issues, quality issues, etc. I've tried ffmpeg on 3 architectures 
now with no issues, although I've not really been paying too much attention 
to the quality.


Cheers,

Tom




More information about the gstreamer-devel mailing list