[gst-devel] Re: ranks (was: Re: [gst-cvs] tpm gst-plugins-good: gst-plugins-good/ gst-plugins-good/ext/cdio/)
Christian Fredrik Kalager Schaller
uraeus at linuxrising.org
Fri Jan 20 07:22:02 CET 2006
Haven't been thinking about a solution for dynamic ranking,
but I have been thinking a lot about the problem space of assigning
rank. The unwritten policy so far have been to give the highest rank to
the one plugin which has the best quality ('quality' unfortunately being
a quite subjective or at least hard proven). I hope/think we should be
able to keep doing this even with the entrance of Fluendo's plugins. I
assume the community would be ok with for instance mad being set to
primary rank, while the Fluendo mp3 plugin to secondary, while for
windows media the open source stuff is secondary and Fluendo's primary
as long as the who gets to be on 'top' is chosen based upon 'which one
is the best'. In most cases I think it be an either or anyway, but
doesn't hurt planing for the case where people have both.
(Although both in relation to mad vs flump3 and ffmpegWM vs FluendoWM
I have no hard 'data' that one is better than the other, I am just
Hopefully this setup will work for the time being, for both the
community and for Fluendo; and that other plugin vendors will try to
follow the same rule.
Only problem I can see coming up is that Fluendo will get in a situation
where we feel a need to rank a theoretically lower quality plugin over a
theoretically higher quality one, due to the 'high quality' one having
bugs which gives our customers a feeling that the product we sell them
have bad quality (ie, they buy our mp3 plugin, but due to some bug in
mad they get problems playing back mp3's and thus blame Fluendo for
selling them a product which doesn't work). I don't really believe this
will become a problem though, as I think the people who buy our plugins
will not have the free ones installed usually and even if they do the
free ones will be bugfree enough to not cause support issues for us. But
only time will tell.
On Fri, 2006-01-20 at 12:55 +0100, Benjamin Otte wrote:
> On Thu, 19 Jan 2006, David Schleef wrote:
> > I also agree with
> > Uraeus that the app maintainers should have the most say in this
> > decision.
> Has anyone ever thought about a good way to automatically determine an
> order for elements? I guess in the future when there might be multiple
> elements that implement a particular feature, there will be quite some
> interest in using the right plugin. And each of them trying to provide a
> higher rank than the others doesn't sound like something we want to aim
> at. (I can imagine Sun mp3 vs Fluendo mp3 vs mad for example, where the
> preference might depend on which one was installed last or which one has
> the higher version or even which one sounds better to a particular user.)
> And it gets especially interesting now that Fluendo "duplicates" quite a
> lot of existing but nondistributable plugins.
> I don't think it's a good idea to make it depend on application developers
> in the long run, because I can easily imagine them disagreeing.
> I'd prefer something that works as automatic as possible but I have no
> clue about how to do that even though I've thought about it for a while.
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel