[gst-devel] Re: [gst-cvs] company gstreamer: gstreamer/ gstreamer/gst/

[Thomas Vander Stichele]

Hi,


> I have recently been quite agreesive in adding all sorts of error checking
> to the core, because there's a lot of things that shouldn't/mustn't happen
> but aren't checked for and then lead to weird issues nobody understands.
> If such a change is invasive and might disable something that worked
> before (like this change) I've carefully checked that things don't break.
> Of course I'm not perfect there either.

I think all of that is good, and I'm happy you're doing this.  All I'm
saying is that it might be preferable - just as other projects do, or
are forced to do - to not break their apps in a cycle where you have
said you would try not to break their apps.  I don't really see the
value in having to do this *now* compared to later.

As a side note, any change to the core of this "magnitude" in effect
should at least be validated by the committer running "make check"
before on what little testsuite we have - three of the testsuite checks
break because of this, which I just fixed.  Esp. when buildbot is down
because of a power failure (gotta love Spain), this is necessary.

I'm not saying this to complain, just an observation on what I think
would be nice if we tried as a team.


> Another recent example you might stumble upon (especially when running
> core cvs with releassed plugins, as all the people will do soon when the
> next core is released) is that return values from getcaps functions are
> checked to be a subset of the template caps. This is something everybody
> expects anyway and it's been a requirement since day 1, so people
> act very surprised when it's not the case (hi Iain). Unfortunately it
> wasn't checked before. So there's lots of plugins that return wrong caps.
> In current cvs this will get you a g_warning and an automatic reduction of
> the caps to be a subset of the template caps. Known offenders in
> gst-plugins 0.8.2 are ximagesink, xvimagesink (the templates advertise
> framerate=[1, 100] but it returns framerate=[0, MAX]), osssink
> (advertising only G_BYTE_ORDER as allowed andianness but also accepting
> non-native byte orders on some soundcards), avidemux (Ronald said that,
> haven't looked yet) and interleave (advertising 0 channels when not
> connected yet). Apart from avidemux all those bugs have been fixed in
> gst-plugins cvs. But expect lots of people to show up complaining about
> warnings once the next core is released...

If it's a warning and it doesn't actually break it, that's fine.  Good
way to get wrong code to be fixed.  Great that you've done this.

Thomas


Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Nothing says "obey me" like a bloody head on a fence.
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/