<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> see below... <blockquote cite="mid1108373577.2845.20.camel@tux.lan" type="cite"> <blockquote type="cite"> <pre wrap="">3) This is minor and a bit of an aside, but should this project be considered an end unto itself or a stepping stone on the path to an improved error handling mechanism in gstreamer itself? It seems to me that if one of the goals of this is for this to be a stop gap solution of sorts for totem users and the like to go find missing plugins and the like, it would be MUCH better to have totem just say directly to the user you are missing plugin x, go to y to download and install what you need... I had a random thought that perhaps this status table could be a way to collect, update and get a working maintenance process around some of data you might need to improve gstreamers error handling for these error cases... </pre> </blockquote> <pre wrap=""> I don't think we can do that,</pre> </blockquote> If the status tables contain a complete list of all supported plugins and the media types they attempt to support, we could hopefully at least provide a list of "Here are the plugins that are available and intended to deal with this type of file." Of course some lists might be empty if gstreamer has no plugin support for certain file types... <blockquote cite="mid1108373577.2845.20.camel@tux.lan" type="cite"> <pre wrap="">We don't know what decodes $mediatype, because that depends on the plugins the user has installed. Multiple plugins can decode a given mediatype, and so on. Not to mention that Fedora and the like may even strip out the useful parts (prticularly mpeg) if we do this inside totem, making it completely useless for our intended purpose. </pre> </blockquote> Even if gstreamer cannot access any file type information from a file if the appropriate plugin is not installed, it could perhaps at least be able to handle some of the most common error cases like "This file ends in (.mov/wmv/mpg), check gstreamers plugin status table page for a list of plugins that may support this type of data(container format)." Once basic container format errors are handled in some fashion the next step would be to beef it up a bit by also mentioning the exact missing codec(s) and such. There may be file type libraries around that may be able to help out with this if gstreamer can't deal with it internally. Whether this is functionality is dealt with by gstreamer or perhaps by a seperate library that all gstreamer based apps could link against is mostly a question for the various core developers... </body> </html>