[gst-devel] gst-ffmpeg & decodebin

[Christian Fredrik Kalager Schaller]

Hi Tom,
That is the behavior we used to use. The problem is that it seemed to
have the opposite effect of the one we wanted. You see people got the
non-problematic packages of GStreamer from the distro (core, base and
good). Then when they wanted mp3 support they realized they needed to
get something else. A lot of them then just grabbed gst-ffmpeg. Problem
was that they got a horrible user experience with all their music
applications crashing constantly. Yet since mp3 sorta did play did
assumed they had the correct packages installed and just concluded that
GStreamer was horribly broken for mp3 playback. So we switched to the
current policy which cause users to try looking for other packages for
mp3 support once the find that gst-ffmpeg do not support it, finding
gst-ugly and getting properly working mp3 playback.

So while we originally agreed with your assessment of the situation our
experience when trying this was that it gave GStreamer a really bad name
and causing a lot more user frustration than the current solution.

Christian

On Wed, 2008-02-06 at 19:33 +0100, Tom Cooksey wrote:

> My personal view point is that this is the wrong behaviour. Only demuxers 
> known _not_ to work should have rank set to NONE, and others should be given 
> MARGINAL. Give GStreamer a fighting chance to play the file. IMO, an 
> occasional segfault for some people is better than never playing the media. 
> As mentioned, if a user does experience a segfault, they can just install 
> another plugin with a higher rank. It might also highlight bugs in ffmpeg & 
> encorage them to be fixed. :-)
> 
> > 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.
> 
> Well... This is tricky. Qt is using GStreamer as it's default phonon back end 
> (for Linux.. at the moment), so all Qt applications using phonon on Linux 
> will be using GStreamer. I don't want to run into the situation where someone 
> writes a media player using phonon, but nobody uses it becuse it can't play a 
> file mplayer, xine or vlc can play. I've been told the KDE devs have written 
> their own phonon back-end for xinelib - so I'm not sure which phonon backend 
> KDE applications will be using. For Qt/Embedded, we have to use GStreamer 
> because we're seeing a lot of embedded boards shipping with GStreamer decode 
> elements which use hardware acceleration specific to those boards.
> 
> 
> 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