[gst-devel] typefind cleanups

[Stefan Kost]

Hi,

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
> though).
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
>>    "video/x-ms-asf"
>>    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
uncommented.

> 
> Cheers
>  -Tim
> 

Ciao
  Stefan

> 
> 
> -------------------------------------------------------------------------
> 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
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel