maybe one way of speeding up the process is, as soon as we get the typefind result, to switch to a different discovery pipeline if the caps are of type "image/*"

Where it takes a lot of time is when it's creating a snapshot of the video stream, which in those cases are 3000x2000 pixel pictures. We don't need to create snapshots if it's jpeg or png.

I think you want to generate the snapshots anyway. You don't want to keep in memory 1000 3000x2000 pictures.

As for the long time, consider that image decoders tend to suck big time in gst, we should fix that.

In fact... for HD content we have more or less the same issue (yes, re-encoding to jpeg/png a 1920x1080 image takes a long time).

Maybe we should insert a videoscale to limit the resolution to a certain width/height in the discoverer. We don't need to store thumbnails as big as that.

These two commits fix the remaining issue. One of them makes push-based scenarios much faster, the other one downsizes the size of the video streams used for thumbnailing if they're greater than 720x720.

commit d5aebe0bf59a7971a9711c0268731b66ceed7994
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Sun May 10 12:01:47 2009 +0200

    Discoverer: Increase the blocksize of the source elements to 128kb
    
    The default value is 4kb ... which makes the decoding of high-bitrate
    content (like 6MPixel photos or HDV footage) in push-mode exceedingly
    slow. Giving 32times more data at once speeds up those scenarios.

commit ab81f4fd774e046d86bec93ec39a665c5973968e
Author: Edward Hervey <bilboed@bilboed.com>
Date:   Sun May 10 11:55:49 2009 +0200

    Discoverer: Limit size of video to thumbnail to 720x720.
    
    We use videoscale in nearest-neighbour mode (which is faster).