[gst-devel] typefind cleanups
ensonic at hora-obscura.de
Wed Oct 24 19:49:38 CEST 2007
Tim Müller schrieb:
> On Wed, 2007-10-24 at 10:54 +0200, Stefan Kost wrote:
>> I believe we need some stricter rules for the gsttypefindfunctions.c.
> Why do you believe that?
Because it looks really messy there. The principle behind the order is not
obvious there, but that can be changed with some comments.
>> Currently typefindplugin works down the registered typefind funtions
>> by ranks and alphabetical sort-order.
>> A quick analysis shows:
>> 38 PRIMARY
>> 46 SECONDARY
>> 8 MARGINAL
>> Alphabetical sorting is done on feature name (e.g. "audio/x-au"). Thus
>> we always first probe "application/", then "audio/", then "image/" and
>> finally "video/".
>> Not really clever, but I have no better idea right now.
> FWIW, "historically", the sorting by name (after rank) was just done in
> order to make typefinding more predictable/determinate, nothing else.
Yes, I've seen that comments.
> The order in which we typefind things mostly matters for typefinders
> that return MAXIMUM probability (since that's when typefinding stops
> immediately and other typefinders are not tried). For all others, it
> doesn't matter that much, or only where two typefind functions return
> the same probability (I don't think I've ever seen a case like that
Well of course the earlier it tries the right one the faster its finished.
>> While looking at the primary ones I stumbled over a few things:
>> * TYPE_FIND_REGISTER (plugin, "audio/iLBC-sh", GST_RANK_PRIMARY,
>> shouldnt that be "audio/x-iLBC" ?
> Does it matter? You could call it "typefinder9983" if you wanted to (and
> the factory name wasn't part of the API, which some may argue it is).
I see, its not used for anything else then.
>> * not really widely used types as primary
>> "audio/qcelp", "text/x-cmml"
>> shouldn't they be secondary
>> * non container based type as primary
>> "audio/x-flac", "audio/x-vorbis", "video/x-theora", "video/x-dirac",
>> "video/mpeg4", "audio/mpeg"
>> shouldn't those be secondary too
>> * container based as secondary
>> shouldn't that be primary
>> Any comments.
> Foremost: please don't make any big changes before the next -base
> release. The current order and typefind probabilities is something
> that's been fine-tuned over quite some time, it's not something that
> should be messed with before a release.
Don't worry, thats why I write here first :)
>> Primary should be widely used container formats.
>> Secondary should be the non-so widely use container formats and codecs.
>> Marginal esoteric stuff
> I think identifying the type correctly should be our primary concern
> with efficiency a second(ary) concern. I'm not sure how ranking
> typefind functions by popularity helps with either. Most typefinders
> for popular formats that can identify their type with MAXIMUM
> probability are already PRIMARY rank as far as I can see (the ASF
> typefinder being a notable exception, which should probably be
> changed). For the others it doesn't really matter that much anyway.
> This is not to say that everything that there is currently makes sense,
> just that I'm not convinced your suggested metrics make more sense.
Well, I thinks its not so useful to try "audio/qcelp" before "video/*". If the
order of things is so precious and important its quite bad that its more or less
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
More information about the gstreamer-devel