[gst-devel] quality/profile interface

[Benjamin Otte]

This sounds an awful bit complicated.

I'm trying to get the requirements now to get an abstract view (This goes
for all the stuff, from quality interface to audio profiles:
- There needs to exists a list of "profiles" to use for $x.
Can we define $x as something generic? Probably not, becuase s-j will not
be interested in video encoding profiles and gst-record will not be
interested in audio-only encoding profiles.
- A "profile" is a description for a part of a pipeline. Or is it an
element's properties? Or both depending on context?
- A "profile" could be defined by elements, applications, users -
essentially anyone?
- A "profile" should then be used by every app using GStreamer.

Is that about right or did I miss something?

Benjamin


On Sun, 4 Jan 2004, Ronald Bultje wrote:

> Hi Ross,
>
> On Sun, 2004-01-04 at 18:48, Ross Burton wrote:
> > Interesting.  Similar in concept to Thomas's gnome-audio-profile
> stuff,
> > but the profiles are hard-coded into the elements. Hmmm.
> [..]
> > Of course, this all needs to integrate with Thomas's g-a-p work
> > too.
>
> The audio profiles stuff seems semi-unfinished. I personally consider it
> too "commandline'ish" (i.e., you just have to type stuff, there's no
> such thing as list selection or so, like in gst-inspect-gui). Also, it
> seems rather focussed on one-stream pipelines (e.g. "mad quality=3
> bitrate=192"), but not on multi-level pipelines (e.g. "mplex profile=9
> name=out { mpeg2enc name=video_in profile=9 ! queue ! mplex.video_00 } {
> ffenc_ac3 name=audio_in ! queue ! mplex.audio_00 }" - see how complex
> this can become?). Now, that doesn't mean I don't like the idea. I think
> gnome-media is a perfect spot for profile editing. But I also think the
> plugin should be allowed to carry a default bag of profiles itself (this
> is most notable if you think about mpeg2enc/mplex, both already carry
> profiles for VCD, SVCD and DVD encoding). Also, the way in which
> profiles are saved should be generic, i.e. not GNOME-specific (think
> KDE, command-line).
>
> More below.
>
> > I'd change the profile names from char* though, if I understand the
> API
> > correctly and the same string will be used for
> gst_profile_set_current()
> > and gst_profile_get_list().  There should be a machine readable ID
> > (int?) used by the API, and a way to obtain a
> human-readable/translated
> > string for the user interface.
>
> [thinking aloud]
>
> Think this: a profile is an object. On an instance of one of my elements
> (e.g. 'mad'), I can set/get the current profile and a list. That's
> simple.
> Now, on the class of the element, I want to be able to fully define new
> profiles, like with GAP. I suppose the whole editing/creation thing (as
> in object code needed to do this) can be in the interface-/lib-code for
> the profiles, and the only operation on the class is to get the list of
> properties (hey, gobject does that for us ;) ) and to add/remove new
> profile, which can (from that point on) be used in the get/set/list
> functions. I don't think we should allow the default profiles to be
> removed/modified. From this list, we can then automatically generate the
> list of affected properties and the get_property_for() values, voila.
> If we go one step further, this add/remove profile from class can also
> be done outside the plugin (I'm sure G-A-P currently does it this way;
> the list/set/get functions then also aren't part of the plugin anymore,
> they're implemented in the lib/interface), and then the only operation
> is to actually 'set properties'. I.e., profiles simply become a
> transparent frontend to properties. Plugins need no new code except a
> list of default profiles plus their affected properties and associated
> values.
>
> For G-A-P in gnome-media, the task then becomes not to provide profiles,
> but rather to be a powerful profile editing app. Imo it should provide a
> list of elements and for a selected element a list of all properties,
> and a list of profiles and for each profile a table of affected
> properties and their values. Its task is then to create new profiles,
> edit current ones, etc. For default profiles, sensitivity of the editing
> stuff is simply FALSE.
> The profile code (interface/object/lib) itself should be added to the
> gst-plugins package, either as art of libgstinterfaces (well, the 'get
> list of default profiles and associated properties/values' is an
> interface function. ;) ), or as a new lib (libgstprofiles).
>
> Sounds awful to me, but I'm probably missing a slight gotcha somewhere
> (it can't be that easy). Almost sounds a bit GConf'ish. ;). Note that I
> have no clue how to save this stuff. In the registry? In a new XML file?
> What about multi-app-usage?
>
> Note that in my idea, profiles affect one element. It'd be even better
> if we could do this in series of elements (like in Thomas' GAP idea),
> but that will become very difficult for applications to use, I'm
> affraid, especially in the harder cases (as I've explained above).
> Slight disadvantage... Maybe others have a better way of doing this.
>
> I had nothing better to do while traveling home, so I wrote a proposed
> header file in the train. See attached, it should go in
> gst-plugins/gst-libs/gst/profiles/ and probably has to be split out over
> profile.h and profilemanager.h. Note that some/most of the
> profilemanager functions can actually be done without an instance of the
> manager, so I'll probably change them to operate on the interface
> (class)... What's missing is a way to load the class of a specific
> element (plugin) without creating an instance. That'd be very useful for
> something like G-A-P. Anyway, that's minor so we'll get to that once
> we're on our way with this.
>
> Comments? :).
>
> Ronald
>
> (hoping that Thomas will now bump in, too)
>
> --
> Ronald Bultje <rbultje at ronald.bitfreak.net>
> Linux Video/Multimedia developer
>