[gst-devel] type finding

[David I. Lehn]

walters is having a slight problem with mp3 type finding.  the code in
gstmp3types.c does a simple check for ID3 tags and a start code at the
beginning of the buffer.  However, this doesn't work for some iradio
streams which do not start the stream at the beginning.  This causes
further type find functions to be called and it turns out festival
plugin decides the mp3 data is actually "text/plain" and it can handle
it.  Oops.

The simple fix for this right now is to have the mp3types.c code scan
the entire buffer it gets for a startcode.  This has a performance
penalty if the buffer is something else.  And it also will fail if not
enough data is available.

[As a side note, this mp3 type code has buffer range errors.  It could,
in theory, segfault if the input buffer is < 4 bytes.  Or more likely,
do type detecting on invalue buffer data!  Probably need to do more
auditing for such errors elsewhere as well.]

Possible longer term solutions might be to let the type find function
return some more info on it's state and have optional effort flag.

An "effort" flag would tell the type find function if it should just
check the front of the buffer or do a more extensive scan through the
whole buffer.

Returned values would be a "confidence" value, a guint64 specifying if
more data is needed to do a higher confidence check, and caps of the
potentially found type.

An algorithm using this would be to scan all type find functions with a
buffer at "low effort".  If "high confidence" caps are found, stop.
Else continue checking.  If nothing is found do a "high effort" check.
This would tell the type find functions to do more extensive check
through the whole stream (or whatever they determind appropriate) in
case the stream is out of sync. (as is the case with walters iradio
stream).  I'm not sure what the failure modes are if this fails too.
Either pick the highest confidence type so far or bail out with an
error.

This sort of thing involves a bit of API change.  Adding effort to the
type find signature:

typedef GstCaps* (*GstTypeFindFunc) (GstBuffer *buf, gpointer priv);

to

typedef GstCaps* (*GstTypeFindFunc) (GstBuffer *buf, GstTypeFindEffort
effort, gpointer priv);

And some flags/values for the effort type.

The return values like confidence and more-data-needed could be added to
caps or maybe that's overloading the caps idea too far:

typedef GstCaps* (*GstTypeFindFunc) (
    GstBuffer *buf, /* buffer */
    GstTypeFindEffort effort, /* effort to use */
    GstTypeFindCapsConfidence *confidence, /* out: result caps confidence */
    guint64 *data_request_size, /* out: need more data */
    gpointer priv);

I think for the immediate fix the mp3 code should scan the entire buffer
it gets.  Which is slower and could fail if buffer is short and has no
start code.  But it's better than nothing.

Thoughts?

-dave