[Rhythmbox-devel] Re: rhythmbox: gstreamer vs xine



On Tue, 2003-01-14 at 09:25, Thomas Vander Stichele wrote:
> Hey Miguel,
> 
> > Hi Thomas,
> > 
> > > I'll be sad to not see Rhythmbox in Red Hat 8.1.  While it was far
> > > from finished, I was looking forward to at least being able to
> > > recommend it to a whole bunch of people I know, and at the college
> > > radio I also work at in my spare time (they moved to RH exclusively
> > > last year, finally).
> > 
> > Just curious... you said that rhythmbox won't be in RH 8.1 and, if i
> > understood it right, that is because the dependency on libxine, right?
> 
> Yeah, that was my reasoning.  Xine got pulled from 8.0 at the last minute 
> as well - it was in the beta for it.

That's because they didn't have time to strip the mp3 playback properly.
The MP3 playback removal came after the Beta.

> But, as Jorn mailed, he never wanted RB in Red Hat 8.1 in the first place, 
> so maybe it wouldn't have made a difference nayway.
> 
> > well, this is something that really puzzles me: redhat removed xine,
> > xmms mp3 support and other (?) software from their distro because of
> > patent issues. now it is including gstreamer and multimedia stuff back
> > in? how is that possible?
> 
> Because GStreamer itself is type-agnostic.  All of the functionality and 
> type handling is provided by plug-ins.  This was one of the design goals 
> at the very start, and patent issues is one reason for it.  Red Hat
> ships plug-ins that are totally free, like vorbis, audio effects, and some 
> other things.

xine is also type-agnostic. It just happens so that the core is shipped
along with the plugins.

> > i never tried gstreamer, so maybe the core itself doesn't contain any
> > patented code (so in this case it should only be able to play ogg, vp3?)
> > or is redhat disabling some parts on compilation?
> 
> Right, the core does just data handling.  As for how to actually disable 
> plug-ins, any of
> a) not having the right deps
> b) disabling through configure
> c) just not listing them in the spec
> will do, so it's really easy to only distribute plugins you want to 
> distribute.

A way to disable some plugins, or move the "dubious" plugins to another
module would be easy enough.

> > i would love to see that problems with patents solved, as well seeing
> > gnome/kde/redhat/mandrake/suse/whatever users enjoying high quality
> > multimedia experience. i just don't know what would be the point in
> > including packages in a cripped form (like not being able to play mp3,
> > because like we or not it's a de fact standard).
> 
> Oh, I don't know.  I think Red Hat made a very brave move in doing this.  
> Does it suck for end users ? Yeah.  Does it make people change their 
> minds.  I hope so.
> It changed my mind - I totally reencoded my collection of CD's on mp3 to 
> vorbis since Red Hat 8.0 came out.  Reencoded, not transcoded.  I'm up to 
> 515 cd's in ogg now.
> So it changed my mind.  I hope it has changed other people's minds as well 
> - at least, the ones that are serious about music, and not just download 
> stuff from the net.  I don't care if pirates can't play their downloaded 
> music anymore :)

That's great if you don't use these files on anything but a computer. I
have hardware that won't play Oggs, only MP3s.

> So, I don't mind.  But of course, it sucks that a standard Red Hat install 
> won't allow you to play lots of the media that's out there.  But what can 
> you do ? It's the patents that are the problem here.

What I was told for Totem:
"We don't currently ship it due to
a) mp3 issues; when we removed the mp3 code from xine-libs, it broke
b) other associated patent issues.

(It was actually suggested that it's better to let users download their
own versions of xine, with decss, etc., rather than ship a stripped-down
one...)"

Which to me sounds fair enough, unless we do some work to make the user
experience better in that case.

> As for how to solve it - that's easy.  We can provide the missing 
> plug-ins, and as long as we can, we will :) Basically, just copying the 
> .so file should be enough anyway.  And we'll be making rpms and debs as 
> well.

Sounds good.

Cheers

-- 
/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




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