[gst-devel] some ideas for a gnome love shot

Ronald S. Bultje R.S.Bultje at students.uu.nl
Sat Apr 24 21:11:18 CEST 2004

Hey dudes,

I recently talked to Jeff and some others regarding our lack of
acceptance in the playback part of GNOME so far (as opposed to Xine).
Take Totem; pretty much anyone uses the Xine backend, and that's mostly
because it's simply better than then GStreamer backend.

Jeff suggested a gnome love shot: that's a massive marketing attempt to
get people to try out Totem-gst and tell us each and any nastiness they
find. That would - of course - include Rhythmbox and other apps, but I
just mention it Totem-gst because that's our biggest issue so far.

OK, no, we cannot just do this. We're too far behind. Specifically, the
CPU use, simplicity and crash-proneness of libgstplay/autoplugging need
to be improved first. Some examples:

* I hear some people tell that libgstplay/spider will crash or refuse to
play back a file alltogether as soon as a substream is not recognized
(e.g. audio in an AVI). This is not good, it should just ignore the
stream and optionally display a message to the user. It should play back
the rest.

* We probably want to do some internal testing of libgstplay/spider
first so we actually know that the default use cases of an app such as
Totem are pretty much crash-free. This includes loading a /dev/random
file, clicking a random sequence of buttons and those things.

* Waiting for a new autoplugger is not a good idea unless it'll be out
there very soon, since it'll simply take too long. We don't want to have
any other task in the world wait because the autoplugger has bugs.

After that, we probably want to go ahead and do this gnome love thingy.
this includes:

* sending email to gnome-love list and possible other lists
* posting on gnomedesktop.org
* posting on linuxtoday.org
* possibly other websites
* possibly other distribution channels

... and asking, in each of them, to test the latest of Totem (and
Rhythmbox and Amarok and Muine and ...) + GStreamer (i.e. this requires
a release of at least all gstreamer packages just before that, we cannot
ask people to use CVS for such wide tests) and make bug reports for any
files that refuse to play back, any obvious crashers, etc. Also, we need
to provide a list of known issues (e.g. .mp4 known to not work, qdm2
known to not work, ...) plus links to relevant bugzilla entries.

The problem here is managability, Luis offered to explain me some basics
of bugzilla management while we're at it, so I'll probably do that as
well. Basically, we need to be very strict on bugs here, make duplicates
where appliccable and get rid of "I didn't run gst-register" bugs ASAP,
etc. ASAP is important because else, it'll get one big mess very soon.
Maybe we can ask Luis to help us if he wants (dunno if that's a good
idea, I guess he has better things to do).

In the end, the idea is:
* improve GStreamer media support (technical).
* fix GStreamer bugs related to Totem-gst (technical).
* improve the understanding in the general public that we're out there
to make a great product that is usable for them, and that we're working
hard on fixing their bugs (marketing).

So, comments? Opinions? Shoot!


More information about the gstreamer-devel mailing list