Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 9 Sep 2004 18:32:35 -0400
From:      michael johnson <ahze@ahze.net>
To:        Adam Weinberger <adamw@FreeBSD.org>
Cc:        Mario Sergio Fujikawa Ferreira <lioux@FreeBSD.org>
Subject:   Re: multimedia/gstreamer-plugins request
Message-ID:  <25838FC2-02B0-11D9-B04C-000A958C81C6@ahze.net>
In-Reply-To: <20040909204128.GQ3649@toxic.magnesium.net>
References:  <947106C2-029D-11D9-B04C-000A958C81C6@ahze.net> <20040909204128.GQ3649@toxic.magnesium.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sep 9, 2004, at 4:41 PM, Adam Weinberger wrote:

> Are there any other ports that require gst-plugins to be built with
> specific dependencies? None others come to mind.

Another example is totem, totem only *needs* gstreamer-plugins (unless  
compiled with xine)
to work but able to play say a xvid file you'd need to recompile  
gstreamer-plugins with WITH_XVID
defined.

> I don't see how this would help. Gst-plugins isn't an incremental  
> build.
> If you want to compile in new support, you need to rebuild the whole
> shebang.

it'd be a little bit of work but it is posable. Gentoo does this, see
http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/eclass/gst- 
plugins.eclass?rev=1.18 to see how they do it.
and http://packages.gentoo.org/search/?sstring=gstreamer shows all the  
gstreamer packages.


> Honestly, I'd rather see energy put into reducing the number of macros
> that we have, not increasing it. The frameworks behind USE_GNOME and
> USE_SDL and the like are not trivial, and IMO shouldn't be implemented
> unless, as is the case for those two examples, there are literally
> hundreds of ports that will be greatly simplified by it.
>
> If you believe that your proposal would simplify things to such an
> extent, I'd like a bit more info about which ports would be simplified
> by it, and what its benefit would be to the end user.
>
> # Adam

Port name:                         Could use PLUGIN:
audio/gnomemedia2       gst-ogg, gst-mad
audio/lindele                     any or all of the audio plugins.
audio/muine                      gst-ogg, gst-mad, gst-flac
    (currently muine only supports xine in ports)
audio/rhythmbox              gst-ogg, gst-mad, gst-flac, gst-faad
audio/sound-juicer          gst-cdparanoia, gst-ogg, gst-flac, gst-lame
    (From Makefile: You must have gstreamer-plugins built with  
Cdparanoia support!")
audio/tunesbrowser       gst-faad (For AAC support)
multimedia/gstreamer-player  gst-gnomevfs, gst-hermes, and others
multimedia/nautilus-media  gst-ogg, gst-flac, gst-mad
multimedia/totem            gst-faad, gst-xine, gst-lame, gst-ffmpeg,  
and more

we would also be able to remove the following from  
multimedia/gstreamer-plugins/Makefile

# hermes is required for gstreamer-player to work
# since it is currently the only colorspace plugin available
WITH_HERMES=    yes
# gnomevfs is required for gstreamer-player to work
WITH_GNOMEVFS=  yes
# Add default MAD support.  This is required for rhythmbox to work.
WITH_MAD=       yes

but I agree you're right about reducing the number of macros and after  
looking through ports there really isn't many
ports that this would effect. but if you take in effect that you use  
something like USE_MULTIMEDIA macro that supports
more than just gstreamer you also could add.

Ports Than can use USE_MULTIMEDIA=xvid
multimedia/avidemux
multimedia/avidemux2
multimedia/avifile
multimedia/gstreamer-plugins
multimedia/mplayer
multimediua/mplayerxp
multimedia/transcode
multimedia/vlc
sysutils/xvidcap

I guess you're right though, maybe when more ports support gstreamer it  
would be worth it but not right now

Cheers,
Michael



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25838FC2-02B0-11D9-B04C-000A958C81C6>