[gst-devel] gst-ffmpeg & decodebin

[Michael Smith]

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
work.


> 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.

Mike