Re: My take on Totem and GStreamer

[Julien MOUTTE <jmoutte electronic-group com>]

Hi Jeff,

I've already done a big part of backend porting in Totem for GStreamer.

As soon as GStreamer core version 0.6.2 will be out it will be really stable and support lot of medias.

IMHO the only big feature which is not in gst enabled totem is DVD playback. And that will be a tough one if we are willing to do it correctly.

I would be really interested to get feedback from people using totem with gstreamer backend to see what's missing in that port.

I would be happy to fix a lot of stuff there if they are easy fix bug with libgstplay.

Cheers

-- 
Julien MOUTTE - jmoutte electronic-group com
C.T.O.
_________________________________________________________

ELECTRONIC GROUP INTERACTIVE - www.electronic-group.com
World Trade Center, Moll de BARCELONA
Edificio Norte 4 Planta
08039 BARCELONA SPAIN
Tel : +34 93600 23 23 Fax : +34 93600 23 10
_________________________________________________________


On Wed, 28 May 2003 21:51:44 +1000
Jeff Waugh <jdub perkypants org> 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.
> 
> 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. :)
> 
> 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. :-)
> 
> - Jeff
> 
> [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.
> 
> -- 
> GU4DEC: June 16th-18th in Dublin, Ireland             http://www.guadec.org/
>  
>       "And, most importantly, we now have modules named 'fontilus' and
>         'themus' -- the two founders of GROME." - Jonathon Blandford
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list