[gst-devel] Roundup

Ronald S. Bultje R.S.Bultje at students.uu.nl
Tue Jun 29 10:10:38 CEST 2004

Hi gang,

I'd like to followup on Benjamin's earlier (valid) point on the sudden
takeoff of many new elements with something that worries me more, and
has worried me for a full year now: most developers don't seem to use
any of our applications, and the result of that is a pretty bad state.
Actually, that's an exxageration, we're doing ok, but we could be doing
a lot better by simply caring about simple things.

Allow me to use the past 0.8.2 gst-plugins release, which didn't even
compile with Totem or Gst-player. Pretty humiliating, if I may say so. I
take blame for not testing the pre-releases, like any of us should.
However, point I want to make here is not this one mistake. Rather, it's
an example of the fact that we have a shitload of outstanding issues not
being worked on by anyone, or being worked on too little, and not being
cared about at all while being extremely important because they are
application blockers.

Allow me to provide some examples:
* alsasink is a complete pain for end users. I've had this working
perfectly on any crappy sound card I could get my hands on a few weeks
ago, but apparently (according to bug reports on bugzilla) the code in
0.8.2 is broken again.
* gnome-volume-control still doesn't list all ALSA tracks correctly
(switches and enumerations) and doesn't react to other applications
changing volume.
* totem/gst-player support only half the formats that other players
(xine, mplayer) support even though we include code to support up to 90%
(mostly through ffmpeg). In most cases, we never even cared to test the
given format, nor do we have test samples available.
* where's our fully featured DVD player that was finished last year?
* application development manual is outdated.
* prolly many, many more... Bugzilla is full of small bugs like this,
we've got nearly 200 by now!

Most of those are well underway and have people working on them, but
progress on them is *very* slow (because those exact same points were
mentioned one and two years ago). At the same time, we seem to add lots
of new code that will be just as badly maintained (I think Benjamin had
a very good point on this in his last email), and ... we're just not
getting anywhere near what we need to be *well* usable by applications,
even for mere playback. No wonder Jorn prefers Xine.

How about we do an application roundup of, say, two weeks in which we
only work on issues related to applications? And how about we continue
testing applications after that? More in detail, how about we spend a
fixed amount of time (two weeks) on actually fixing bugs instead of
adding new, broken, badly implemented features that we will fix in a
wrong way later on? This includes the bugs mentioned above, but probably
many more. It also includes someone finally going through the whole
bunch of testfiles that I and others have referred to several times and
telling us which work and which not, and actually fixing the broken
ones. Thing is, I can give a list of very specific things-to-do and
things-to-fix, but that list needs manpower to be gone through
completely. IOW: I need help for that.

I've spent the past few months (for as far as I actually had time)
solely on fixing such issues, and Benjamin helped me a lot by fixing
several invalid referencing bugs and memory issues, but I just cannot
get it done alone. I've tried for four months, and I failed (and I
assure you that it's mostly very boring, too). Let's get it over with
and work on it together for a while and have an even better product
after that.


More information about the gstreamer-devel mailing list