From: <ram...@ya...> - 2003-10-04 12:58:24
|
Bejamin, I think that you missed one point. The goal of GStreamer is to translate the mental model of the user into a pipeline implementation. The spider element is a good example of that. What the user expects is: "I want to translate this format into this format". The user does not know the name of the elements of GStreamer. ("User" might be an application programmer). Otherwise, a new GStreamer release with new element names could break existing applications. It would be risky to commit to not changing neither element names nor properties. Now, let us suppose that user Dick wants to record his brother's wedding into an ASF file. Dick does not know much about computers, let alone GStreamer. So the application cannot ask it about asfmux, and not certainly about asfmux properties. The application just cannot go further than asking about the output format. Perhaps ASF is too complicated for Dick, but the application cannot guess it. With the implementation that you suggest, either Dick or the application would have to know that asfmux needs an special parameter to generate files that can are intended to be stored in the hard drive, as opposed to streaming. It is obvious that Dick cannot be expected to know that. Even Jan, a Linux entusiast that recompiles the kernel everyday and writes his own drives, and has just downloaded GStreamer because it sounds cool, cannot know it. So the application should know it. But there are too many output formats. The application should not be required to have special knowledge about any of them. I agree what I think that Ronald tryied to say. As there are different output formats, the behaviour of asfmux should not depend on one property of the element, but on one property of the caps of the output pad. Thus filesink should report the fact that the file is intended to be written to a file by setting a property in the caps. Now the application would simply use something like (oh, excuse me, I do not know the syntax for filter caps so I will explain them bellow): v4lsrc ! spider !(1) spider !(2) filesink (1) should have a caps filter so that the first spider knows what video encoding it should use. (2) should have properties so that the second spider knows that it should output ASF instead of AVI or OGG. In conclusion, the application should tell GStreamer what format conversion is desired, not what particular elements should be used. Doing so ensures that the mental model of the user is translated into the right pipeline implementation. Hope this helps, Ramon ___________________________________________________ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es |