[gst-devel] quality/profile interface

[Benjamin Otte]

(ccing Ross for sound-juicer)

My idea was totally different. My idea was to provide a "slider" in the
range [0, 1] for the quality. You set a value there and the element
figures out how to translate that to its own settings. Since some elements
only provide X different features. you need some sort of granularity.

So the API would look something like this:
/* quality getting setting */
gdouble        gst_quality_get_quality       (GstQuality *quality);
/* returns the actually set value */
gdouble        gst_quality_set_quality       (GstQuality *quality,
                                              gdouble     value);

/* figure out how much one "step" inside the slider is */
gdouble        gst_quality_get_granularity   (GstQuality *quality);

/* get (translated) description for quality that can be shown
   next to the slider. Optional for elements, if they don't
   implement it, we return g_strdup_printf ("%d", get_quality()) */
gchar *        gst_quality_get_description   (GstQuality *quality);
gcahr *        gst_quality_get_description_for_quality
                                             (GstQuality *quality,
                                              gdouble     value);

The only problem I have with this approach is that one quality setting
is not very much. The things I want to decide on are
- quality
- bitrate
- encoding time
which obviously affect each other. So multiple sliders might be an idea,
too. But it might be too complicated... If so, add a "GstQualityType type"
to each function and a
typedef enum {
  GST_QUALITY_QUALITY,
  GST_QUALITY_BITRATE,
  GST_QUALITY_DURATION
} GstQualityType;
to the prototype. I think that's too complicated for an interface that's
supposed to be simple though.

Benjamin


On Sat, 13 Dec 2003, Ronald Bultje wrote:

> Hi *,
>
> I promised to send down some ideas for a quality/profile interface. The
> idea/goal is simple: a plugin can have N (0-inf) properties that affect
> encoding quality, and each can have different values, of which each
> value has a different meaning for the output quality and encoding time
> (or CPU requirements). Some are top-down, others are down-top (so if a
> property has allowed range 1-5, which is best and which is worst?).
>
> We could do this with properties, but that requires some knowledge from
> the users, which is against the Gnome philosophy. So we need something
> simple and uniform.
>
> To overcome this issue, I (with others) propose a profile interface.
> It's a simple "link properties and values to a meaning" interface. The
> only issue is: how should it look and behave?
>
> I propose a limited list, defined by the plugin, with free-form strings
> that indicate a certain quality setting. Each of these "profiles" is
> fixed (for simplicity). The profiles affect several GObject properties,
> and have fixed values for each of them. I propose the following
> functions to get this:
>
> /* get the list of profile IDs */
> const GList *gst_profile_get_list (GstProfile  *profile);
>
> /* set/get the current profile - NULL means none (i.e.
>  * the current element configuration does not apply to
>  * a specific profile). */
> const gchar *gst_profile_get_current (GstProfile  *profile);
> void         gst_profile_set_current (GstProfile  *profile,
> 				      const gchar *id);
> /* maybe ID needs to be a struct instead of a string? */
>
> /* get affected properties (list of GParamSpecs) */
> const GList *gst_profile_get_affected_properties (GstProfile *profile);
>
> /* get the value of a property for a specific profile ID */
> void         gst_profile_get_property_for (GstProfile *profile,
> 					   GParamSpec *pspec,
> 					   GValue     *value);
> /* value is just like for GObject properties */
>
> That's it. If the current configuration in an element does not apply to
> a certain profile ID, then we simply return NULL or so. It means
> 'Custom', i.e. not a pre-configured profile, but something set by the
> user itself. I don't think this is an issue, since if a user sets
> properties manually, he knows what he's doing. Note that apps will only
> use the first three functions, the last two are just for 'advanced' apps
> that want to show information to the user or so.
>
> Comments? Different opinions? Things unclear that need better
> explanation? Please let me know!
>
> Ronald
>
> --
> Ronald Bultje <rbultje at ronald.bitfreak.net>
> Linux Video/Multimedia developer
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>