[gst-devel] gst-player CVS
Thomas Vander Stichele
thomas at urgent.rug.ac.be
Thu Sep 26 02:37:02 CEST 2002
> On Thu, Sep 26, 2002 at 10:37:05AM +0200, Thomas Vander Stichele wrote:
> > > How about this patch?
> > I was about to commit, then realized that this should be done in the app,
> > not in the library. Meaning, gst-player should try to render, and if it
> > fails, use it's default settings instead of having it crash.
> > What do you think ?
> Well .. i agree in principle but gst-gconf API is trying to make
> things automatic.
What it currently does is allow for any "partial pipeline" to be parsed
into one element. Nothing more than that. So it doesn't really know
that you're asking for an "audio-type" sink or source, so it doesn't have
or should have the knowledge to fall back to a reasonable default.
> If the error recover should be done in the
> app then some of the code should come out of the plugin and
> into the app since the fallback case needs that code anyway.
For me, the dividing line was "give an app a one line function call to get
the default desktop output method for this type". There are apps who
might, from that point, just error out (because they're lazy ;)) or there
are apps who try to work around it. Of course ideally the gconf key
should be set right anyway, but that's another matter.
What I basically wanted to avoid when I created this gconf helper lib is
a) some apps that only try to do an element_factory_make from the gconf
key, which would cause them to fail if the gconf key setting was for
example osssink sync=false
b) each app having it's own copy of code that does proper parsing.
> What do u suggest? Only developers are likely to hit this case anyway ...
What I'm doing right now is adding some code to gst-player that throws up
a warning to ask you to inspect the key. I'll see what that brings out
as a problem in the gconf helper lib.
I'm all for adding some more stuff to the helper lib (probably starting
with GError stuff so that it's more descriptive), but I prefer to not
anything that tries to second-guess the user or administrator, like
choosing xvideosink as a default if the key could not be parsed.
Of course I might be totally wrong on this so I'm still taking
suggestions, but having thought about this a lot this week this is how I
feel about it currently ;)
I'll put up another prerelease when I have all the warnings working so you
can see how it works.
The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/
morgen wordt het beter beter voor iedereen
dan krijg ik de strop
en jij wat je verdiende
<-*- thomas at apestaart.org -*->
URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
More information about the gstreamer-devel