[gst-devel] type finding

Benjamin Otte in7y118 at public.uni-hamburg.de
Mon Feb 3 04:06:17 CET 2003

On 30 Jan 2003, Colin Walters wrote:

> Your API changes look good to me.  I would say though that we shouldn't
> worry a lot about the performance penalty; after all, in the common case
> GStreamer will have filename extensions to work with.
> Also, it might be good for apps to have a way to give hints to the
> autoplugger about the expected media type (I didn't see a way to do this
> currently).  So that way the autoplugger could try those types first,
> with both low and high effort, and only later fall back to other types.
Some thoughts about this:

I think that needed effort should be a parameter when registering the
typefind func, not when calling it. Mp3 would then register 2 functions,
one with less effort and one with more effort.
Typefinding would order all its functions by effort and go top down.
Second advantage: More common types could get a higher effort value and
be called earlier. Mp3 is more common than Mod these days...

The second thing we should implement when we change this stuff is to
include a value on how big a buffer this typefinding function needs in the
worst case. This would allow spider to stop typefinding once it has
collected such a buffer without missing any possible types.

I'd like to implement this btw
(/me hears thomasvs shout 'fix spider first' from behind)


More information about the gstreamer-devel mailing list