From: Wim T. <wim...@ch...> - 2000-08-19 16:28:58
|
Hi, While writing the manual, I came across one of the main problems with the typedetect and autoplug stuff. I first explained the method we are using now: creating the elements *by name*. Now I'm explaining the method of creating the elements by MIME type, which is the way to go if we want to have multiple decoders for the same MIME types. Some functions exist to search for an element with a given MIME type. What I don't want to explain in the manual is how you are going to construct a pipeline like this: dirsksrc->mp3parse->mpg123->audiosink with only the gst_type_get_by_id() function. I would like to have something like GList *gst_type_get_src_to_sink(src_id, sink_id) to retrive a list of elements that will form a pad from audio/mpeg to audio/raw. The algorithm would try to find the shortest pad between the two types which can be a very generic operation. The programmer does not need to know that there are several elements involved to create this pipeline. Erik, this is closely related to autoplugging you mentioned in several documents. Where would a function like this fit in best? We should probably also preconnect the pads, in which case we should better have something like: GstBin *gst_bin_autoplug(src_id, sink_id); or GstBin *gst_bin_autoplug(GstElement src, GstElement sink); The point is that for the common case the app programmer would only have to do: create src create parser (or have it autodetected) create sink with gst_type_get_sinks(type) add above elements to main_pipeline get a bin that connnects the parser to the sink add bin to pipeline run pipeline instead of: create src create parser (or autodetect) create sink (some logic to find out that the MIME type of the parser is not audio/raw) { (some more logic to find an element to convert the type of the parser to audio/raw) (find out that such an element does not exist or that there a five of them) (take an element that sinks the type of the parser) { (find an element that sinks this type) (find out that this element does not src audio/raw) more horror... } } very hard to explain... When I come to think of it... We could even add a flag to the pad like: GST_PAD_SUGGEST_THREAD so that the bin returned from the autoplug call would be a thread with a queue if some element suggests it. This would make creating a five threaded MPEG player trivial: create src create parser (or autodetect) create videosink create audiosink get bin to connect parser to videosink get bin to connect parser to audiosink run internally all the elements would be resolved using MIME types so that the user can switch MPEG decoders on the fly... *very* cool if that would work out... If you hav no objections, I would try to implement this idea. Wim -- QOTD: "What women and psychologists call `dropping your armor', we call "baring your neck." |