[gst-devel] gst-ffmpeg & decodebin

[Tom Cooksey]

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

I understand what you mean now, thanks for the clarification. Having said 
that, perhaps a new rank could be defined called BETTER_PLUGIN_EXISTS or 
something. If decodebin finds that the rank is BETTER_PLUGIN_EXISTS it can 
emit a warning saying something like "While this plugin may work, it is 
unsupported and better plugins are known to exist. It is highly recomended 
that you install the better plugin".

There's still the issue of codecs where it's ffmpeg or nothing. If there's no 
alternetive, I still think GStreamer should try ffmpeg, emiting the 
appropriate warnings.

Mike> I appreciate you're probably not too bothered about embedded, but the 
difference between 21% and 23% CPU on a mobile device is very important. It 
can almost be directly translated into 10% longer battery life for example. 


Cheers,

Tom