[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