[gst-devel] gst-ffmpeg & decodebin

[Christian Fredrik Kalager Schaller]

Hi Tom,
There is a list defining the rank on a per codec basis in one of the
gst-ffmpeg header files if I remember correctly. The reason it got
disabled back in the day was because if you tried seeking in a mp3 file
using that decoder you would get an error and the application would
crash. This might not be the case anymore with the new mp3parse element
taking care of the seeking, but I don't think anyone has verified.

If you are using gst-ffmpeg in your project you can of course change the
rank of any of the codecs easily for your own build/setup if you so
prefer.

Christian


On Wed, 2008-02-06 at 18:35 +0100, Tom Cooksey wrote:
> 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
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel