Re: Presets and profiles

[David Joaquim <david joaquim gmail com>]

Christian Fredrik Kalager Schaller a écrit :
> The device profiles is not meant to solve all the problems in the world,
> they are meant to solve a limited set of problems :)
>   
Definitly, but for me profile is more general that just device.
>
> 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.
>   
I think about it as a preconfigured set of settings.
Avoiding to reconfigure each parameter every time.

We may first agree on the definition of profile :p

> Not sure what you want to accomplish
>
>   
A profile can be a triplet :
 - A video pipeline
 - An audio pipeline
 - A muxer.

When you define a profile, you set the values for the triplet.
theora for video, vorbis for audio, oggmux for the muxer, with a set of
per element properties.

A device profile is the same, but, with various limitations.
For example a profile for iPod is limited to a subset of all video/audio
codecs and muxer.
x264 for video with a maximal size, complexity and bitrate, aac for
audio and mp4 muxer.

You can configure the iPod profile using these limitations.

Of course the final profile is a static thing. You just select it, and
use it.
I was talking about how users may want to configure a profile.

We can provide a finite set of predefined profile.
However,  I think it is more interesting to also provide a interface
that permits to create customized profiles.

The lambda user will use the predefined profile without asking questions.
An advanced user may create his own profile and save it into the profile
list.
Later he can reuse it.


> 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.
>   
Sure.
My point was that end user doesn't care about which element he is
currently using.
He just want to know which parameters it can interact with.
The idea is to pack multiple element's properties (they which are
interesting), and provide an high level configuration.

If you want to encode a video in a different format and size, you don't
care about configuring format element (the encoder), and the resizer.
You just want to specify theora 300x200, and the api will do the job to
configure the underlying things.

> 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.
>   
In that case you may also want to create the pipeline manually :)
I think profile is the convenient way to configure an encoding.
As I mean profile is like a set of parameters.
>> 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.
>   
Of course, but being generic make the generation harder.
>   
> What kind of API do you provide at this point?
>   
For the moment we have something like that (not exactly, but lets say it
is the case):

EncodingItem {
    GFile *source;
    GFile *destination;
    Profile *profile;
}

void
transcode(EncodingItem *item);

The transcode function takes the source get the parameters from the
profile (we use something like gst-launch now) and encode and write it
to the destination.
Internally we use a decodebin to get raw audio and video and then
connect the pads to the encoders.

As pointed out in an other post, we can do better job in case of remuxing.

About the profile manager.

Similarly to the Banshee player, we have a set of profile-descriptors.
It defines the format (ogg, mp3, aac, flac, ...).
It essentially defines what properties you can interact with and their
default values.

We have an UI that permits the interaction with the parameters and save
the result into a profile.
A part of the UI is still manually done, but we want to generate it
automatically from the profile descriptor.
The code is not so clear, we may benefit to code it in python or another
high-level language.


> 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.
>   
Yes, thanks to point that out.
I have to agree with the other developers, but I think it will be ok.


I hope you have a more precise idea of what I mean by profile.
I'm pretty sure we didn't think about it the same way :)

David