[gst-devel] Re: [gst-cvs] wingo gstreamer: gstreamer/gst/elements/

Ramón García ramon_garcia_f at yahoo.com
Sat Oct 4 05:59:02 CEST 2003

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,

Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...

More information about the gstreamer-devel mailing list