[gst-devel] Possible ABI problems with gstreamer 0.8.4
Brian.Cameron at Sun.COM
Thu Jul 29 08:09:32 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.
I think sending an email similar to this one prior to each release would be a
good reminder, if it isn't being done already.
>>* 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.
Yes, that would be great!
>>* 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.
Apologies. You are right. I tested the older 0.8.1 release, and it is broken
too. On the up-side, I figured out how to get this working using either 0.8.1
or gstreamer 0.8.4/gst-plugins 0.8.2 . Changing my default sink to:
"audioscale ! audioscale ! audioscale ! esdsink" corrected this problem.
>>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. :)
Right. It would be nice if people in general could be a bit more proactive
in testing the various gstreamer applications.
More information about the gstreamer-devel