2007/2/23, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net">magnus.bergman@observer.net</a>>:<div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Fri, 23 Feb 2007 21:26:26 +0800 "Fabrice Colin" <<a href="mailto:fabrice.colin@gmail.com">fabrice.colin@gmail.com</a>> wrote: > On 2/23/07, Magnus Bergman <<a href="mailto:magnus.bergman@observer.net"> magnus.bergman@observer.net</a>> wrote: > > What gstreamer does is to set up a pipeline for handling media > > streams in a very generic way. The pipeline consists of a source > > element, any number of filter elements and a sink element (which > > could be an indexer of a document viewer). There are currently no > > filter elements for handling text (except for subtitles and such). > > But filters for converting, let's say word documents to plain text, > > could very well be implemented as gstreamer elements. The benefit > > from this is that the documents are streamed instead of first > > downloaded (if necessary) and then converted (all in-process), > > which is of course much faster. And gstreamer can automatically > > figure out which elements are needed and set up an appropriate > > pipeline for doing the job. > > > OK, I see. I agree that streaming documents is a better approach. > > Most, if not all, third-party libraries to access and manipulate the > document types I am interested in don't allow for document streaming. > Basically, if I adopted a stream-based approach, I wouldn't be able > to make use of the wealth of code that's been written, tested, > debugged and optimized by others, and writing filters would be a much > more difficult task. That's true, but not a problem as I see it. Both approaches could be used in parallel. A gstreamer based pipeline could be used as a stand alone filter. And an element for gstreamer wrapping stand alone filters could also easily be written (there might even already be one packaged with gstreamer). > Jos tried to get me to adopt the document streaming code he wrote for > Strigi. I declined for the same reason. The time I would spend > writing low-level document decoders is better spent elsewhere. My point was not so much to prefer streaming over stand alone filters. But rather to prefer gstreamer over some other streaming framework. Since we already have gstreamer which is relatively robust and well tested it would be a waste to add another streaming framework as well.</blockquote><div> Forgive me being naiive - but I've always just related gstreamer to audio and video streams, never with documents streaming on a more abstract level. Can you give some examples on how you've used gstreamer in non audio/video cases? Cheers, Mikkel </div> </div>