[gst-devel] quality/profile interface

[Ronald Bultje]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profiles.h
Type: text/x-c-header
Size: 4621 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20040104/f2a547c7/attachment.bin>