Re: port Brasero to opensolaris

[Brian Cameron <Brian Cameron Sun COM>]

Lin:

> > future releases of brasero (see video branch in SVN) will require even 
> > more plugins from bad (vcdimager, dvdauthor, all mpeg2 plugins...) and 
> > also from ffmpeg gstreamer plugin set. So if one distro doesn't 
> > support bad plugin set that means no video discs could be created. 

I suspect you mean "ugly" plugins rather than "bad".  Ugly plugins
include those plugins which are encumbered, such as MPEG2.

The Gstreamer "bad" plugins are mostly just plugins which are not
finished or which have quality issues.  I would notify the GStreamer
team which "bad" plugins you depend on.  This way they can prioritize
getting them migrated to the gst-plugins-good module.  This way, we
can minimize the number of "bad" plugins that users may need to install
to get Brasero fully working.

> > Apart from that, a switch can be created conditioning the creation of 
> > the normalize plugin.
> Yes, I think it's a good idea to use gstreamer. I strongly suggest 
> brasero plugins based on bad or ugly should be built conditionally 
> because I believe OpenSolaris is not the only one which has the problems 
> to ship Gstreamer bad/ugly plugins. I'm glad to see Brasero can create 
> video discs, but unfortunately I probably have to disable this feature 
> on Solaris. Anyway it's not the worst thing, we still have the Brasero. :-)

It does make sense to make all features that depend on optional plugins
optional.  It would be best if Brasero checked at runtime if the plugins
were available, and made the features accessible only if so.  This way,
if users install the bad plugins, Brasero would "just work" without
needing to be recompiled.

Note that most distros that might want to ship Brasero probably do not
have license to ship MPEG2 plugins.  So, I imagine video creation would
likely be disabled by default on most distros.

> > Of course, there are other methods to do normalizing and video discs. 
> > In the latter case we could create vcdimager and dvdauthor plugins. 
> > But the benefits of using gstreamer are :
> > - it's well supported and integrated
> > - it allows to avoid many temporary files (which eat hard drive space)
> Sure, I understood.

Our plan would be to use Brasero with GStreamer, though we would not
ship any encumbered plugins by default.  As you point out, this probably
means that some functionality will be disabled unless the end user
installs additional plugins.

> > Gstreamer allows to transcode one video file in its final result in 
> > one operation. Otherwise, we'd have to create temporary audio files 
> > for AC3, MP2 audio streams, one video stream MPEG2 and then 
> > remultiplexing all those files into the final one.
> > It also allows during this single operation to apply any filter/effect 
> > we want (size, video/audio format, ...) instead of having to create 
> > another temporary file for each operation.
> > In the case of normalizing, it allows to normalize files whatever 
> > their format/encoding is. There are tools to do normalizing that but 
> > they usually work for a limited set of audio formats (only mp3 or only 
> > ogg, ...). With Gstreamer, when a new audio format is supported 
> > (through a new plugin), this new format will also be supported by our 
> > normalizing plugin. This is priceless since we don't have to care 
> > about which audio formats are supported.
> Good feature. Let me involve Brian Cameron, core developer for Solaris 
> Media project. Maybe he has some ideas about Gstreamer issue, at least 
> for Solaris. I personally like to see built option like 
> "--enable-plugins=mp3,ogg,..." to help us to remove the dependency of 
> gst-bad/ugly. :-)

We should be working to migrate any "bad" plugins that Brasero depends
on to "good".  As I say above, most distros won't be able to ship any
"ugly" plugins by default.  Though end users might install them by hand.

It would be best if Brasero detected plugins at runtime and enabled
features when plugins exist.  This way users don't need to recompile
Brasero to enable features.  The point of using a pluggable GStreamer
interface is that user's shouldn't need to recompile end-user
applications when plugins are added or removed.

> > One note though, Luis said we already have a switch (--enable-preview) 
> > to build brasero with or without gstreamer. That's not entirely 
> > correct since this switch only conditions the building of the video 
> > widget used for preview not gstreamer which is used unconditionally 
> > throughout brasero.
> OK, I hope you or other developers who is familiar with the part code 
> can work on the option to pick out the bad/ugly related code, since I 
> don't think I have the qualification right now.
> BTW, I have tested --disable-preview on the currently trunk, building is 
> *failed*. I think it's a bug.

As I say above, we would want to use Brasero with GStreamer.  We just
won't be able to ship any encumbered plugins by default.  Ideally,
Brasero should "just work" regardless of which plugins are installed.
Features in Brasero should just become enabled when the right plugins
are available

.Brian