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

[Benjamin Otte]

On Fri, 2 Jul 2004, Thomas Vander Stichele wrote:

> Hm,
> while I agree that it's a problem I don't think this is a change we can
> make in the 0.8 series at all.  It breaks apps that aren't doing
> anything wrong to make a point to apps that are doing it wrong.
>
No, it breaks apps that are doing something wrong. You should only link
pads when they are already in a bin, not before. Such a behaviour is
buggy.
So the only reason not to apply this patch would be a broken application.
If there is such an application in wide circulation (I consider apps
like Rb, totem-gst or gnome-media "wide circulation"), we should not apply
this patch to not break buggy applications that rely on a broken feature.
But if there is no application yet, it's IMO a good idea to apply it right
now, so nobody starts writing such an application.
So if people run cvs with all these applications (and you all do that
right now, right? ;)) an all these applications work, stricter error
checking is a good thing.

> Isn't there some better way this can be checked, like checking this in
> the scheduler when going to PLAYING ?
>
Feel free to implement something if you think it's necessary. The problem
was that people were doing this in their apps which lead to some weird
errors that were hard to debug. So I went ahead and made it error out as
it should.

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.

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...


Benjamin