[gst-devel] Possible ABI problems with gstreamer 0.8.4

Benjamin Otte in7y118 at public.uni-hamburg.de
Thu Jul 29 03:46:03 CEST 2004


Quoting Brian Cameron <Brian.Cameron at Sun.COM>:
>
> However, after upgrading my system to use the new versions of gstreamer
> and gst-plugins,  I have discovered that both nautilus-audio-view and totem
> no longer work with certain plugins.  
> 
It should be known to all package managers by now that they are supposed to test
prereleases and make sure they don't break anything. If they figure out anything
breaks, they are supposed to file a bug about it. Even filing the bug after a
release is already broken is ok, we might revert that change for a next release.
But without people actually testing the releases we cannot guarantee stuff still
works. We already have a set of automated tests that we verify before each
release on our buildbots and we'll gladly add new ones, we just can't come up
with them ourselves.
So please test (pre)releases, write automated tests and file bugs about it
before it's too late.

> * nautilus-media: In the function gmi_set_mime in file media-info-priv.c
>    it calls gst_element_get_pad (priv->decoder, "src"), which returns
>    NULL when trying to play a WAV file and this causes an assert.  On
>    Solaris, this causes nautilus to hang and become unusable without
>    killing the process.  In talking with the gstreamer team on
>    #gstreamer, it seems that this problem is caused because the wavparse
>    plugin has been changed to use a "sometimes" pad to work in spider.
>    Since the pads are not created until runtime, they are not available
>    to nautilus media anymore, and cause this assert.
> 
This is something that probably has been broken since 0.8.2 has been released,
and most likely quite some time before in CVS and in the prereleasses. Apart
from that it was a deliberate choice to switch to a SOMETIMES pad to fix
playback of mp3s in Rhythmbox.
Looking at the frequency of Rhythmbox issues with wav playback (I remember at
least 10 bugs in our bugzilla) and nautilus-media issues with wav files (your
mail, never noticed before) I wouldn't revert that change for 0.8.3.
Though it might be possible to work around this depending on what nautilus-media
does by adding to wav decoders, one for nautilus-media and one for spider.
Npnetheless, someone should fix nautilus-media. 

> * totem: Seems to be a similar problem.  The function gst_wavparse_fmt
>    calls gst_pad_set_explicit_caps, which calls gst_pad_try_set_caps,
>    and this returns GST_PAD_LINK_REFUSED.  In the debugger, I notice
>    that the failing call to gst_pad_try_set_caps passes in a pad which
>    has a name "src".  And I get these errors:
> 
>    gstpad.c(2489):gst_pad_set_explicit_caps:<wavparse0> failed to negotiate
>     (try_set_caps with "audio/x-raw-int, endianness=(int)1234, width=(int)8,
>     depth=(int)8, signed=(boolean)false, rate=(int)22050, channels=(int)1"
>     returned REFUSED
>    scheduler( 8181) gstoptimalscheduler.c(2612):gst_opt_scheduler_iterate:
>     <GstOptScheduler at 3bb480> in error state
> 
> In talking with gstreamer developers on #gstreamer, it seems that these
> problem were caused because the wavparse plugin has been changed to use a
> "sometimes" pad to work in spider.
> 
I'm pretty sure this file never played in totem even with older versions. If it
does and still fails with gst-plugins CVS, file a bug against GStreamer with the
file attached.

> If the gstreamer team decides to release a new version of gstreamer
> that causes various applications to break, I recommend that this
> be made clear in the release notes.  I also recommend that the
> gstreamer team notify the various module maintainers who depend on
> gstreamer (nautilus-media, totem, etc.) that the new release of
> gstreamer may break their programs.
> 
The GStreamer team to my knowledge decided to never release code in a stable
release that breaks existing applications, unless the behaviour of those
applications was seriously broken, in which case the application developers will
be notified.
Unfortunately there's this little caveat I mentioned above called "testing".
Knowing a change breaks one of GStreamer's applications is required before any
action can be taken. :)

Benjamin




More information about the gstreamer-devel mailing list