Re: My take on Totem and GStreamer



>   3) Include Totem using the Xine backend for now, and use the GStreamer
>   backend when it matures. This means that a single module in our release
>   would depend on Xine.
...
> Option 3 is unattractive for a number of reasons. Firstly, we have already
> shipped GStreamer in our desktop release (essentially committing to it), so
> it would not make sense to add another media framework. It would negatively
> impact GStreamer progress, testing and bugfixing, and may have an impact on
> integration issues. Distributions may be less inclined to ship Xine due to
> patent issues (they'd have to disable certain plugins, and even modify the
> "pristine source" because they can't distribute it). I'm told that the Xine
> dudes would be happy to split out the difficult plugins and source, though.
> I haven't investigated portability problems, but that may come into play. :)
> 
> That said, the distribution issues could be dealt with, and it will give us
> a media player that works right now.

Which is what most users are going to care about, as much as I think
gstreamer is cool and awesome. Getting Xine to be shippable with distros
sounds like a serious and potentially fatal hurdle, but at this point I
don't even really think gstreamer is ready to be an "out of the box"
media framework behind Totem... even assuming the Totem gstreamer
backend is perfected. AFAIK Xine currently supports many more formats
(at least, more in the realm of modern formats that people will want to
use), and is pretty good at JustWorking(TM) with no configuration and
tweaking. I have not had this experience with gstreamer, though I must
say that its improved a lot, and will hopefully be strong and ready for
2.6.

The nice thing about Totem is that if we ship Xine for 2.4, when we
transition to Totem with gstreamer behind it for 2.6 nobody should
notice (except hopefully that things are stronger, smarter, faster,
better ;-)

The only issue that I would be seriously concerned about is if shipping
a Totem'd Xine will further hamper the surprisingly lethargic rate that
gstreamer is acquiring plugins for "modern" video formats. I've heard
tell that somebody is trying to develop a gstreamer plugin that will
allow the use of Xine plugins, so perhaps that problem will be remedied
by a bridge, but for now its a serious gstreamer issue as far as user
experience is concerned.

Even with that though, I really think we shouldn't be holding our breath
for gstreamer and should ship what works now and switch Totem to the
fresh new gstreamer backend at such point as that provides a better user
experience.

> [1] Which, as it happens, I don't think should be in the desktop release (I
> don't think music library management is a 'greatest common factor' feature)
> but should be blessed in an official GNOME release of sorts.

Rhythmbox isn't "music library management" software, its a music player,
which is pretty basic functionality at this point. I think music
playing, video playing, and making presentations are the most desired
"tasks" not yet handled by GNOME (though of course, we're still waiting
on stable GNOME2 ports of some even more important software like
Gnumeric and AbiWord, so perhaps its not fair to say that these are
currently covered).

-Seth




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]