Re: Presets and profiles

[Christian Fredrik Kalager Schaller <uraeus gnome org>]

On Tue, 2009-05-05 at 20:13 +0200, David Joaquim wrote:
> Hi,
> 
> The idea to develop highlevel gstreamer libraries is really nice!
> 
> Some thoughts about your proposal.
> 
> First I see one problem, or rather a limitation of your DeviceProfile.
> Why a profile should necessarily be associated with a device ?
The device profiles is not meant to solve all the problems in the world,
they are meant to solve a limited set of problems :)

> I'm thinking about a profile library that replaces the current horrible,
> gnome-media profile "framework".
> The profile system may be used by any gnome application (Sound-Juicer,
> ...), but may also define profiles that did not correspond to any
> specific device.
> Who uses flac for a portable player, or even a TV ?
> The fact is that people may want to be able to create a any gstreamer
> supported format profile.
Well there comes a point where defining profiles stop having a meaning :)
A profile that allows you to do anything isn't really a profile anymore.

> Now, the DeviceProfile is not a bad idea at all. It is definitely a
> great idea!
> We can imagine to build it on top of the general profile library.
> Strictly speaking an DeviceProfile is a profile with some limitations
> (the one from the device).
> 
> We can also put device information into profile, merging GeneralProfile
> with DeviceProfile.
> Like: This profile can be used for: iThing, Nokia, ...
Not sure what you want to accomplish

> What do you think ?
> 
> Second, the presets.
> Preset is cool, but seems limited to just one element. (Did I
> misunderstood something ?)
No they are limited to one element, but of course any application and/or
library interacting with them would group them in some way.

> The problem is that in many cases your pipeline contains many elements
> and also caps.
> 
> A simple example is this mp3 encoding :
> 
> ... ! rate=44100, channels=2 ! audioconvert ! lame mode=4 vbr-quality=7
> ! xingmux ! id3v2mux ! ...
> 
> Where xingmux is used to add xingheader to the vbr file, and the
> id3v2mux used to pass tags to the output file.
> 
> Therefore, how to configure all of them at the same time ?
Well that would be the job of a helper library or the application right? 
If you have two encoders and all you want to do is have them both use a
'High Quality' preset you have an api applying that preset to both your
encoders.

> Then :)
> 
> Let me explain how I imagine things from now.
> 
> We need three things :
> 
> * A Profile Library (definitely with a device specific support!)
> * A transcoding library
> * A set of UI components and application
> 
> The profile library is used to create, store, edit, profile (low level).
> 
> The transcoding library is used to transcode files between differents
> formats.
> It uses directly profiles to configure the transcoding operation.
Not necessarily. Profiles makes sense for certain kind of problems,
for instance devices which has a relatively static set of properties.
So a profile system is good for getting values you can feed into a
transcoding/encoding library, but it would never be the only source for
such information. One could for instance have an application where you
set every value manually.

> The main problem is to generate the pipeline from the profile desciption.
Well in some sense  implementing it is the easy problem, the hard thing
is deciding what kind of API and what kind of features such a library
would offer.

> The set of graphical component is designed for integration, simlilarly
> to the current gnome-media-profile.
> There are predefined components, each gnome application can directly
> include it.
> 
> A profile manager can also be part of the graphical components. As
> standalone/integrated application.
> 
> 
> What I can offer:
> I'm currently a developper of gnac, an audio converter: 
> http://gnac.sourceforge.net/download/
> 
> What we have :
> * a profile manager: really simpler than the gnome-media one.
> 
> The main problem now is that the UI of the manager is not automatically
> generated.
> You cannot, for example, add a new format like the celt codec without
> writing some code.
> The goal is that you can pass a "format description" and then the UI is
> automatically generated.
> It also needs many code cleaning :)
> 
> * a C transcoding library
> It currently supports, audio transcoding, video transcoding, external
> subtitle integration (incrustation, or inclusion if the output format
> supports it).
> 
> I think we can adapt this library to fit the new needs.
> The main point is to define what will be the interface of the library.
> 
> I hope this contribution will help to build a new shiny set of highlevel
> components to gstreamer!
What kind of API do you provide at this point?

Also one thing you probably want to do right away is relicense all the
code to the LGPLv2.1. If it is to be integrated into GStreamer at some
point it would need to be under that license.

Christian