GNOME Bugzilla – Bug 346563
gstgnomevfssrc doesn't run typefind
Last modified: 2006-07-05 06:42:26 UTC
gstgnomevfssrc doesn't run typefind on the first buffer. If the element gets added to the pipeline dynamically (i.e. by decodebin), further decoding will fail because the caps on the source pad will remain GST_CAPS_ANY.
Created attachment 68357 [details] [review] Patch to add typefind to gstgnomevfssrc.c
Yet it does not fail in practice with playbin/decodebin, since decodebin will automatically plug a typefind element. _If_ gnomevfssrc is supposed to do typefinding, it a) should do so properly if pull-mode is supported (with random access) b) it should probably work similarly to filesrc, which has a "typefind" boolean property which is disabled by default However, personally I don't really think this is something that needs fixing at this point. And in any case, typefinding a single buffer isn't really enough/possible in many cases, especially with non-local sources where you might get very small buffers. The typefind element takes care of that (and of proper error handling in the EOS-before-we-could-find-a-type case etc.). I am aware of your bz2dec issue and I know I asked you to change it to do typefinding, so admittedly there's an inconsistency, but my answer to that would be that "sources are special" :) In 0.11/0.12 we might want to do something better here (like application/x-typefindme caps or something like that).
I agree that we should do typefind outside of the gnomevfs element. I just uploaded a patch for gstdecodebin that does typefind for each element that has GST_CAPS_ANY on its source pad: http://bugzilla.gnome.org/show_bug.cgi?id=341524. *** This bug has been marked as a duplicate of 341524 ***