Re: My take on Totem and GStreamer

[Bastien Nocera <hadess hadess net>]

And my comments,

On Wed, 2003-05-28 at 12:51, Jeff Waugh wrote:
> So,
> 
> I believe that totem is the absolute best media player available for GNOME,
> and there is no doubt that it should be added to the desktop release at some
> stage.
> 
> It provides full-featured video capabilities, and supports audio for casual
> listening (rather than music library management, etc). IMHO, this summarises
> the greatest common factor of media player use cases amongst desktop users.
> Alongside excellent music library management software such as Rhythmbox [1],
> we have all bases thoroughly covered.
> 
> However, it is unlikely that it will make it into 2.4 for the following
> reasons:
> 
>   - It currently uses Xine to achieve full functionality and performance
> 
>   - It is highly unlikely that the GStreamer backend will be working to a
>     similar degree by feature freeze, or even by release (unless someone
>     else pitches in and does the libgstplay and gstreamer work required)
> 
>   - We have "blessed" GStreamer by adding it to the desktop release in 2.2,
>     and it makes a modicum of sense to not ship two multimedia backends
> 
> To me, that leaves us with three options:
> 
>   1) Don't include totem in the release at all until all of the GStreamer
>   stuff is ready for it. This means that we won't have a media player in our
>   desktop release for 2.4.
> 
>   2) Make sure someone commits to having totem and the GStreamer bits all
>   working for 2.4. This means we'll most likely have a media player in 2.4,
>   and it will be based on the "blessed" multimedia framework.
> 
>   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.
> 
> So, options 2 and 3 are the most interesting, because option one just flat
> out sucks. We might have to live with it, but the other options are there,
> so let's see how they pan out.
> 
> Bastien has said that he is not interested in getting the GStreamer backend
> working in the 2.4 timeframe. I can understand this, because, from his point
> of view (and, I'm sure, the point of view of his users), he already has a
> full-featured media player that works very well. It doesn't make a lot of
> sense to go porting it to another backend that (thus far) is not as capable.

Hmm, that makes me look like an ogre there. What I said was that I
didn't have the time to "fix gstreamer". Totem is pretty much feature
complete, there's about 2 days of work needed to get accessible
subtitles working with the xine backend. So Totem will soon reach 1.0.

When it's there, I'm going to move into bug-fixing/maintenance mode.

> So, if option 2 was going to be viable, I believe that an interested person
> (possibly but not necessarily from the GStreamer project) would have to get
> this going. It occurs to me that, if the GStreamer guys really want to show
> that GStreamer is *the* multimedia framework to satisfy GNOME's needs, then
> perhaps they could concentrate on this in the 2.4 timeframe. As it stands,
> GStreamer doesn't capably satisfy GNOME's needs (though I have no doubt that
> it has the capacity to when these issues are resolved).
> 
> 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. :)

xine-lib works on pretty much every Unix-like OSes, including Sun
Solaris, Linux, *BSD, MacOS X and cygwin.

> That said, the distribution issues could be dealt with, and it will give us
> a media player that works right now.
> 
> Of the two, I think the majority of people would prefer option 2, because it
> proves the multimedia library that we've already "blessed", and it doesn't
> introduce another dependency. Thus far, no one has committed to it, however.
> 
> Those are my (frank and open, though not meant to be taken personally or as
> flamage) thoughts, please discuss. :-)

-- 
/Bastien Nocera
http://hadess.net

#2  0x4205a2cc in printf ("Oh my %s\n", preferred_deity) from
/lib/i686/libc.so.6 printf ("Oh my %s\n", preferred_deity);
Segmentation fault