[gst-devel] gst-ffmpeg & decodebin
msmith at fluendo.com
Wed Feb 6 17:58:49 CET 2008
On Wed, 2008-02-06 at 18:35 +0100, Tom Cooksey wrote:
> 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?
If they worked, then sure, that would be reasonable. They don't work
properly (though they may work in sufficiently simple cases; I'm not
sure). It's much better to give them zero rank, otherwise people who
have installed gst-ffmpeg, but not gst-plugins-ugly, would get lots of
crashes - it's much better to only autoplug plugins that we expect to
> 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?).
Most of the ffmpeg decoders have a non-zero rank. I think there might be
some demuxers with non-zero rank too, but not many - the ffmpeg demuxers
are generally not very good, and gstreamer has native implementations of
most of those.
It's defined inside gst-ffmpeg; you can see the rank using gst-inspect.
> 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.
I don't recall the specific problems with the ffdec_mp3, I do know that
mad is far more reliable, and far more complete. We generally consider
those to be more important than a very small performance difference.
More information about the gstreamer-devel