[gst-devel] Possible ABI problems with gstreamer 0.8.4

[Brian Cameron]

Benjamin:

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

-- 

Brian