GStreamer presets (feedback requested)

[Christian Fredrik Kalager Schaller]

Hi,
I have been working for a while on defining GStreamer level presets
based on the current plugin level preset system. The general document
for those presets can be found here:
http://gstreamer.freedesktop.org/wiki/PresetDesign

My current set of .prs files can be found here:
http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets

I think I have managed to sort out what should be in the files at this
point, including what kind of values makes sense and what kind of values
do not make sense. Even tried documenting those choices on the wiki
pages.

Before I start committing these .prs files to the various GStreamer
modules I would like to ask people to take a look at them and the
current specification and let me know if people:
a) agree with the type of values I have choosen for the .prs files
b) agree with the actual values choosen for some of these values.
Especially the actual bitrates choosen for the Quality settings might
need some polishing (and maybe even more than 3 different options)

These presets can be used independently, but I plan on using them as
part of the device level profiles, linked from the Preset page. But
those profiles are still in a flux and will most likely change a bit, so
please disregard that page for the time being or at least see it as a
work in progress.

Christian




------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[michael smith-6-3]

On Tue, Jun 23, 2009 at 11:06 AM, Christian Fredrik Kalager
Schaller<[hidden email]> wrote:
> Hi,
> I have been working for a while on defining GStreamer level presets
> based on the current plugin level preset system. The general document
> for those presets can be found here:
> http://gstreamer.freedesktop.org/wiki/PresetDesign

After some discussion on IRC, I finally figured out what the presets
are actually _for_ - I initially totally misunderstood.

So to clarify:
 - the profiles are ONLY to map some specific known profile names to a
set of property values for a particular element, so that if you have
two different encoder implementations (which both support the same
basic semantics, but have different property names, or different
units, etc.) you can set things up without knowing the specifics of
the encoder.

They're NOT for providing a drop-down of different encoding settings
in your application, or anything like that. There are a number of
major problems with trying to use them for that purpose (which is what
I initially thought they were for). Your application still has to
provide that layer entirely.

In my opinion, this is not very helpful. In reality, if you have two
different encoders, either:
 - they support the same semantics, so making them use the same
property names/values for that is simple.
 - they support different things, so just mapping names/values/etc
doesn't help you at all

On to some specifics about the presets you've proposed:
 - Where you have things like "Quality High", you've just selected a
bitrate. But, that only makes sense at a particular size of input
(resolution/framerate/etc for video, number of channels, sample rate
etc for audio). Why not just a preset called "Bitrate 128kbps"? That
maps equally well to the underlying properties, but doesn't imply
anything about quality - which is good, since the preset is _only_
setting the bitrate, and actually doesn't have anything to do with
quality.
 - Some presets are designed to be applied along with others, some are
mutually exclusive (e.g. for AAC, the profiles are mutually exclusive,
but a profile and a bitrate can both be selected). But there's no
information provided about which is which. So, an application just has
to hardcode profile names, so this isn't in practice at all
extensible.


I think in practice what people want is an "encoding profile" that
specifies things more completely - e.g. for audio, it might say
"stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and
have a name of "Medium quality Foo Audio" (this would need to be
translateable somehow, but that's a different issue). You could
provide a replacement profile with the same name using a different
encoder, of course.

Summary:
 - I don't think the aims are clear.
 - I don't think the current proposal works very well for what its
aims are, OR for what people are likely to think its aims are.

Mike

>
> My current set of .prs files can be found here:
> http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets
>
> I think I have managed to sort out what should be in the files at this
> point, including what kind of values makes sense and what kind of values
> do not make sense. Even tried documenting those choices on the wiki
> pages.
>
> Before I start committing these .prs files to the various GStreamer
> modules I would like to ask people to take a look at them and the
> current specification and let me know if people:
> a) agree with the type of values I have choosen for the .prs files
> b) agree with the actual values choosen for some of these values.
> Especially the actual bitrates choosen for the Quality settings might
> need some polishing (and maybe even more than 3 different options)
>
> These presets can be used independently, but I plan on using them as
> part of the device level profiles, linked from the Preset page. But
> those profiles are still in a flux and will most likely change a bit, so
> please disregard that page for the time being or at least see it as a
> work in progress.
>
> Christian
>
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Daniel Taylor-6]

On Tue, 2009-06-23 at 19:06 +0100, Christian Fredrik Kalager Schaller
wrote:
> Hi,

Hey,

> I have been working for a while on defining GStreamer level presets
> based on the current plugin level preset system. The general document
> for those presets can be found here:
> http://gstreamer.freedesktop.org/wiki/PresetDesign

This looks pretty good in my opinion, as discussed on IRC.

> My current set of .prs files can be found here:
> http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets

I think the .prs files are also looking good. As discussed before, I
think it would be good to use the textual names rather than the
numerical ones when available, e.g. pass=pass1 instead of pass=17
because it isn't easy to guess what 17 stands for.

I also think that any quality based setting needs to have the pass set
to quantizer or quality mode, e.g. for x264enc we want the Normal
Quality preset to include e.g. pass=qual quantizer=21 or something
similar. The Main Profile could then be used to restrict the settings
and the Pass 1 profile could be used to make it an average bitrate-based
encode rather than a quality one, which is useful for many devices. So
for example:

Load Normal Quality
 * pass=qual
 * quantizer=21
 * dct8x8=true
 * ref=3
 * bframes=3
 * me=umh
 * subme=6
 * threads=0

Load Baseline Profile
 * dct8x8=false
 * bframes=0
 * cabac=false

Load Pass 1
 * pass=pass1

Final settings on the element (x264enc Normal Quality, Baseline Profile,
Pass 1):
 * pass=pass1
 * quantizer=21 (unused)
 * dct8x8=false
 * ref=3
 * bframes=0
 * cabac=false
 * me=umh
 * subme=6
 * threads=0

After this you are responsible for setting a sensible bitrate based on
either the output dimensions/framerate or the device you are encoding to
(which may also need vbv limits like the iPod).

So the basic idea is to have the quality presets set the maximum
possible quality and have other presets based on profiles or multi-pass
to restrict those settings. This means that of course the order of
loading presets matters and should be communicated to users and
developers in some sane way.

Some other random thoughts that I had while we talked via IRC:

 * DivX Home Theater NTSC/PAL profiles should be available for MPEG4
   ASP encoders (xvid, ffenc_mpeg4, etc)
 * xvidenc really needs to output video/mpeg4 or something so that is
   shows up as an encoder if you request MPEG4 video

Since you mentioned the device profiles are still a work in progress I
won't talk about them here, other than to say that they do still need
some work (I'm modifying the Arista preset format somewhat to
accommodate things like subtitle rendering for various devices). I guess
this will all be discussed at some point once the presets are in
GStreamer trunk.

Take care,
--
Daniel G. Taylor
http://programmer-art.org

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Daniel Taylor-6]

Michael,

On Tue, 2009-06-23 at 15:30 -0700, Michael Smith wrote:
> So to clarify:
>  - the profiles are ONLY to map some specific known profile names to a
> set of property values for a particular element, so that if you have
> two different encoder implementations (which both support the same
> basic semantics, but have different property names, or different
> units, etc.) you can set things up without knowing the specifics of
> the encoder.

Correct, though it is also useful in the following scenario: if several
H.264 encoders exist in your GStreamer installation, then you can
request something like "video/x-h264 Baseline Profile" and GStreamer
would give you an H.264 encoder that supports that profile (it is
possible that one would support Baseline and Main, another support all
profiles, and yet another could be a highly optimized High Profile only
encoder). The point is to basically add feature information in a
standardized way to the various encoders that is easy to load as a
preset.

> They're NOT for providing a drop-down of different encoding settings
> in your application, or anything like that. There are a number of
> major problems with trying to use them for that purpose (which is what
> I initially thought they were for). Your application still has to
> provide that layer entirely.

However, they CAN be used for this purpose. Choosing a profile is a
useful action in many cases, especially when encoding for various
devices. My ultimate goal is of course to hide all this behind the
device profiles themselves as is currently done in Arista, but there's
no reason that Transmageddon can't let a user select profiles and
qualities based on these preset files.

> In my opinion, this is not very helpful. In reality, if you have two
> different encoders, either:
>  - they support the same semantics, so making them use the same
> property names/values for that is simple.

Generally true, though it's possible encoders support different types of
profiles as in the example above, and forcing every application to save
which settings are required for which published profiles for every
encoder type is insane.

>  - they support different things, so just mapping names/values/etc
> doesn't help you at all

It will eventually let you query for a suitable encoder for a particular
format and/or device. Those that do not support what you need are not in
the query results.

> On to some specifics about the presets you've proposed:
>  - Where you have things like "Quality High", you've just selected a
> bitrate. But, that only makes sense at a particular size of input
> (resolution/framerate/etc for video, number of channels, sample rate
> etc for audio). Why not just a preset called "Bitrate 128kbps"? That
> maps equally well to the underlying properties, but doesn't imply
> anything about quality - which is good, since the preset is _only_
> setting the bitrate, and actually doesn't have anything to do with
> quality.

Agreed - I think all quality presets should set the quantizer and set
pass=qual or pass=quant as in my other email. Bitrates should be the
responsibility of the developer or the device profiles, being set to
either satisfy some quality constraint via a formula that takes into
account physical dimensions and framerate of the output or the physical
limitations in bitrate and buffer size of the device you are encoding
to. Again I talked a bit more about this in my other email.

>  - Some presets are designed to be applied along with others, some are
> mutually exclusive (e.g. for AAC, the profiles are mutually exclusive,
> but a profile and a bitrate can both be selected). But there's no
> information provided about which is which. So, an application just has
> to hardcode profile names, so this isn't in practice at all
> extensible.

I also agree with this. Along with some being mutually exclusive the
order matters as values can be overwritten. Perhaps a type field could
be added to group presets, then during loading warnings or exceptions
can be raised if a "profile" type is loaded after a "pass" type and
such? Not as extensible as we might like but I'm trying to think within
the limits of the preset format.

> I think in practice what people want is an "encoding profile" that
> specifies things more completely - e.g. for audio, it might say
> "stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and
> have a name of "Medium quality Foo Audio" (this would need to be
> translateable somehow, but that's a different issue). You could
> provide a replacement profile with the same name using a different
> encoder, of course.

This is what the device profiles are for, which internally will use the
encoder presets to select encoding profiles, qualities, etc. The preset
files are a necessary change before we start locking down a device
profile format which will result in giving you and others the profiles
you want to see.

> Summary:
>  - I don't think the aims are clear.
>  - I don't think the current proposal works very well for what its
> aims are, OR for what people are likely to think its aims are.

I hope some of this mail cleared that up; if not let me know. To know
where I am coming from you can take a look at Arista
( http://programmer-art.org/projects/arista-transcoder ) - my goal is a
generic system for such profiles in GStreamer, and Christian deserves
most of the credit for really trying to get things going in a generic
way and into GStreamer trunk.

If you still think these presets/profiles won't do what you want - any
ideas on how to go about getting the results you'd like to see other
than saying that our approach won't work?

Take care,
--
Daniel G. Taylor
http://programmer-art.org

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller]

Hi,
So based on the feedback from Mike and Daniel I took a look at the
current presets. It seems we already do use non-bitrate settings for
quality for everything but a few video codecs. So I guess we should
simply fix those (including ffenc_mpeg4).

For audio however I notice that most codecs only seem to have a bitrate
setting to tweak, only Vorbis of the ones I looked at got a 'Quality'
setting we could use instead. As far as I understand bitrate is relative
to the number of channels. So if you use the same bitrate for a stereo
stream and a 5.1, then the quality of sound for each of the 6 channels
in 5.1 would be quite bad (or the stereo bitrate would be silly high).
Not sure how to fix that apart from maybe having presets called

"Quality Normal 6-Channels"
"Quality Normal Stereo"

Tim suggested on IRC that to avoid the kind of confusion that MikeS
mentioned we should probably call the Profiles something little less
'human readable', like Quality/Normal/6-Channels for instance.

Mike mentioned he would like standardized property values instead of the
presets. Which also goes into another question which is if we are to at
some point try to put the media format profiles into the caps (like
making 'Low Complexity' for AAC a caps)

I talked to Wim a bit more about this today and he didn't see how either
standardized properties or profiles in caps where really viable
solutions. So for the time being I will continue with assuming that
presets will be our solution for these issues.

Also if a system is put in place which allows us to mark certain presets
as mutually exclusive I wouldn't mind adding support for that in the prs
files. It is worth nothing though that the way things work now is that
nothing will 'fail' if you apply 'mutually exclusive' presets. What
happens is that if one preset sets cabac to false and
another to true, the final value will be of the last preset applied.

Christian

On Thu, 2009-06-25 at 10:23 +0200, Daniel G. Taylor wrote:

> On Tue, 2009-06-23 at 19:06 +0100, Christian Fredrik Kalager Schaller
> wrote:
> > Hi,
>
> Hey,
>
> > I have been working for a while on defining GStreamer level presets
> > based on the current plugin level preset system. The general document
> > for those presets can be found here:
> > http://gstreamer.freedesktop.org/wiki/PresetDesign
>
> This looks pretty good in my opinion, as discussed on IRC.
>
> > My current set of .prs files can be found here:
> > http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets
>
> I think the .prs files are also looking good. As discussed before, I
> think it would be good to use the textual names rather than the
> numerical ones when available, e.g. pass=pass1 instead of pass=17
> because it isn't easy to guess what 17 stands for.
>
> I also think that any quality based setting needs to have the pass set
> to quantizer or quality mode, e.g. for x264enc we want the Normal
> Quality preset to include e.g. pass=qual quantizer=21 or something
> similar. The Main Profile could then be used to restrict the settings
> and the Pass 1 profile could be used to make it an average bitrate-based
> encode rather than a quality one, which is useful for many devices. So
> for example:
>
> Load Normal Quality
>  * pass=qual
>  * quantizer=21
>  * dct8x8=true
>  * ref=3
>  * bframes=3
>  * me=umh
>  * subme=6
>  * threads=0
>
> Load Baseline Profile
>  * dct8x8=false
>  * bframes=0
>  * cabac=false
>
> Load Pass 1
>  * pass=pass1
>
> Final settings on the element (x264enc Normal Quality, Baseline Profile,
> Pass 1):
>  * pass=pass1
>  * quantizer=21 (unused)
>  * dct8x8=false
>  * ref=3
>  * bframes=0
>  * cabac=false
>  * me=umh
>  * subme=6
>  * threads=0
>
> After this you are responsible for setting a sensible bitrate based on
> either the output dimensions/framerate or the device you are encoding to
> (which may also need vbv limits like the iPod).
>
> So the basic idea is to have the quality presets set the maximum
> possible quality and have other presets based on profiles or multi-pass
> to restrict those settings. This means that of course the order of
> loading presets matters and should be communicated to users and
> developers in some sane way.
>
> Some other random thoughts that I had while we talked via IRC:
>
>  * DivX Home Theater NTSC/PAL profiles should be available for MPEG4
>    ASP encoders (xvid, ffenc_mpeg4, etc)
>  * xvidenc really needs to output video/mpeg4 or something so that is
>    shows up as an encoder if you request MPEG4 video
>
> Since you mentioned the device profiles are still a work in progress I
> won't talk about them here, other than to say that they do still need
> some work (I'm modifying the Arista preset format somewhat to
> accommodate things like subtitle rendering for various devices). I guess
> this will all be discussed at some point once the presets are in
> GStreamer trunk.
>
> Take care,
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Julien Moutte-2]

Hi,

My opinion is that there's no perfect solution to that problem and that
having presets will cover probably 70% of apps requirements and users needs.

This is probably a good start. Most applications should expose an
advanced configuration tab though where users can see the properties of
the element to tweak further.

A common effort to unify properties names and formats plus presets plus
advanced tabs would already bring us to an acceptable situation.

We are preparing a set of encoding codecs for the Fluendo store and we
will try adapting those codecs to the presets and unifying properties names.

PS: that's an interesting topic to raise during the GStreamer get
together event in July.

Cheers,

Julien



Christian Fredrik Kalager Schaller wrote:

> Hi,
> So based on the feedback from Mike and Daniel I took a look at the
> current presets. It seems we already do use non-bitrate settings for
> quality for everything but a few video codecs. So I guess we should
> simply fix those (including ffenc_mpeg4).
>
> For audio however I notice that most codecs only seem to have a bitrate
> setting to tweak, only Vorbis of the ones I looked at got a 'Quality'
> setting we could use instead. As far as I understand bitrate is relative
> to the number of channels. So if you use the same bitrate for a stereo
> stream and a 5.1, then the quality of sound for each of the 6 channels
> in 5.1 would be quite bad (or the stereo bitrate would be silly high).
> Not sure how to fix that apart from maybe having presets called
>
> "Quality Normal 6-Channels"
> "Quality Normal Stereo"
>
> Tim suggested on IRC that to avoid the kind of confusion that MikeS
> mentioned we should probably call the Profiles something little less
> 'human readable', like Quality/Normal/6-Channels for instance.
>
> Mike mentioned he would like standardized property values instead of the
> presets. Which also goes into another question which is if we are to at
> some point try to put the media format profiles into the caps (like
> making 'Low Complexity' for AAC a caps)
>
> I talked to Wim a bit more about this today and he didn't see how either
> standardized properties or profiles in caps where really viable
> solutions. So for the time being I will continue with assuming that
> presets will be our solution for these issues.
>
> Also if a system is put in place which allows us to mark certain presets
> as mutually exclusive I wouldn't mind adding support for that in the prs
> files. It is worth nothing though that the way things work now is that
> nothing will 'fail' if you apply 'mutually exclusive' presets. What
> happens is that if one preset sets cabac to false and
> another to true, the final value will be of the last preset applied.
>
> Christian
>
> On Thu, 2009-06-25 at 10:23 +0200, Daniel G. Taylor wrote:
>> On Tue, 2009-06-23 at 19:06 +0100, Christian Fredrik Kalager Schaller
>> wrote:
>>> Hi,
>> Hey,
>>
>>> I have been working for a while on defining GStreamer level presets
>>> based on the current plugin level preset system. The general document
>>> for those presets can be found here:
>>> http://gstreamer.freedesktop.org/wiki/PresetDesign
>> This looks pretty good in my opinion, as discussed on IRC.
>>
>>> My current set of .prs files can be found here:
>>> http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets
>> I think the .prs files are also looking good. As discussed before, I
>> think it would be good to use the textual names rather than the
>> numerical ones when available, e.g. pass=pass1 instead of pass=17
>> because it isn't easy to guess what 17 stands for.
>>
>> I also think that any quality based setting needs to have the pass set
>> to quantizer or quality mode, e.g. for x264enc we want the Normal
>> Quality preset to include e.g. pass=qual quantizer=21 or something
>> similar. The Main Profile could then be used to restrict the settings
>> and the Pass 1 profile could be used to make it an average bitrate-based
>> encode rather than a quality one, which is useful for many devices. So
>> for example:
>>
>> Load Normal Quality
>>  * pass=qual
>>  * quantizer=21
>>  * dct8x8=true
>>  * ref=3
>>  * bframes=3
>>  * me=umh
>>  * subme=6
>>  * threads=0
>>
>> Load Baseline Profile
>>  * dct8x8=false
>>  * bframes=0
>>  * cabac=false
>>
>> Load Pass 1
>>  * pass=pass1
>>
>> Final settings on the element (x264enc Normal Quality, Baseline Profile,
>> Pass 1):
>>  * pass=pass1
>>  * quantizer=21 (unused)
>>  * dct8x8=false
>>  * ref=3
>>  * bframes=0
>>  * cabac=false
>>  * me=umh
>>  * subme=6
>>  * threads=0
>>
>> After this you are responsible for setting a sensible bitrate based on
>> either the output dimensions/framerate or the device you are encoding to
>> (which may also need vbv limits like the iPod).
>>
>> So the basic idea is to have the quality presets set the maximum
>> possible quality and have other presets based on profiles or multi-pass
>> to restrict those settings. This means that of course the order of
>> loading presets matters and should be communicated to users and
>> developers in some sane way.
>>
>> Some other random thoughts that I had while we talked via IRC:
>>
>>  * DivX Home Theater NTSC/PAL profiles should be available for MPEG4
>>    ASP encoders (xvid, ffenc_mpeg4, etc)
>>  * xvidenc really needs to output video/mpeg4 or something so that is
>>    shows up as an encoder if you request MPEG4 video
>>
>> Since you mentioned the device profiles are still a work in progress I
>> won't talk about them here, other than to say that they do still need
>> some work (I'm modifying the Arista preset format somewhat to
>> accommodate things like subtitle rendering for various devices). I guess
>> this will all be discussed at some point once the presets are in
>> GStreamer trunk.
>>
>> Take care,
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[michael smith-6-3]

On Thu, Jun 25, 2009 at 1:46 AM, Daniel G. Taylor<[hidden email]> wrote:

> Michael,
>
> On Tue, 2009-06-23 at 15:30 -0700, Michael Smith wrote:
>> So to clarify:
>>  - the profiles are ONLY to map some specific known profile names to a
>> set of property values for a particular element, so that if you have
>> two different encoder implementations (which both support the same
>> basic semantics, but have different property names, or different
>> units, etc.) you can set things up without knowing the specifics of
>> the encoder.
>
> Correct, though it is also useful in the following scenario: if several
> H.264 encoders exist in your GStreamer installation, then you can
> request something like "video/x-h264 Baseline Profile" and GStreamer
> would give you an H.264 encoder that supports that profile (it is
> possible that one would support Baseline and Main, another support all
> profiles, and yet another could be a highly optimized High Profile only
> encoder). The point is to basically add feature information in a
> standardized way to the various encoders that is easy to load as a
> preset.

This seems like a useful bit of functionality - but it'd be much
better to be able to query this programatically from the element,
rather than having to rely on someone having written appropriate
preset files.

>
>> They're NOT for providing a drop-down of different encoding settings
>> in your application, or anything like that. There are a number of
>> major problems with trying to use them for that purpose (which is what
>> I initially thought they were for). Your application still has to
>> provide that layer entirely.
>
> However, they CAN be used for this purpose. Choosing a profile is a
> useful action in many cases, especially when encoding for various
> devices. My ultimate goal is of course to hide all this behind the
> device profiles themselves as is currently done in Arista, but there's
> no reason that Transmageddon can't let a user select profiles and
> qualities based on these preset files.

I thought so too originally, but there are problems with that: the
presets don't have any i18n capabilities, for one.

>
>> I think in practice what people want is an "encoding profile" that
>> specifies things more completely - e.g. for audio, it might say
>> "stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and
>> have a name of "Medium quality Foo Audio" (this would need to be
>> translateable somehow, but that's a different issue). You could
>> provide a replacement profile with the same name using a different
>> encoder, of course.
>
> This is what the device profiles are for, which internally will use the
> encoder presets to select encoding profiles, qualities, etc. The preset
> files are a necessary change before we start locking down a device
> profile format which will result in giving you and others the profiles
> you want to see.

The device profiles are a much more important part of this. I think
those are interesting. I don't think the presets help with this.

The reason for separating the presets seems to be some idea that there
will be many different encoders for every format, all using different
configuration options. I simply don't believe that this is likely.

I expect that every new encoder will either
  a) be simple, and not have many configuration knobs - and those that
it has will be fairly standard things like bitrate
or
  b) be substantially more complex, and a customised profile will be
desirable to take advantage of the encoder's capabilities.

Because of this, I do not see the benefit in separating the presets
from the profiles - I think in all cases, either the preset isn't
needed (because everything is standard) OR enough things will be
different that a different encoder profile is needed. I also think
that it's _generally_ going to be uncommon to have many different
encoders.

In short: we should concentrate on really capable encoding profiles, instead.

Mike

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Tim-Philipp Müller-2]

On Thu, 2009-06-25 at 09:16 -0700, Michael Smith wrote:

> > However, they CAN be used for this purpose. Choosing a profile is a
> > useful action in many cases, especially when encoding for various
> > devices. My ultimate goal is of course to hide all this behind the
> > device profiles themselves as is currently done in Arista, but there's
> > no reason that Transmageddon can't let a user select profiles and
> > qualities based on these preset files.
>
> I thought so too originally, but there are problems with that: the
> presets don't have any i18n capabilities, for one.

This should be easy to add, I think - it could probably be made to work
the same way it's done for .desktop files. In fact it even looks like
the preset files have the right markup for that already (leading '_' for
fields with translatable strings), but maybe that's just coincidence.

Cheers
 -Tim



------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller]

> Because of this, I do not see the benefit in separating the presets
> from the profiles - I think in all cases, either the preset isn't
> needed (because everything is standard) OR enough things will be
> different that a different encoder profile is needed. I also think
> that it's _generally_ going to be uncommon to have many different
> encoders.
Well having re-written Transmageddon to use the presets I have to say
that I do find them a useful way of organizing the information and makes
doing the device profiles easier.  And I think that the xvidenc and
ffenc_mpeg4 elements show that the presets are capable of providing a
useful abstraction. And if people do not find them useful they of course
don't need to use the preset files.

> In short: we should concentrate on really capable encoding profiles, instead.

Agreed, and that is part of the effort here. And I hope to be able to
push them forward another step during GUADEC. But what it is not obvious
to me is what you want from these profiles. I haven't been able to see
from your feedback so far if you think we are on the right track, but
some adjustments are needed or if you think we are totally barking up
the wrong tree. If the second I think you need to show us some kind of
example of what you are trying for as currently you seemed to have
mostly focused on what you don't want as opposed to what you want.

Christian


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Thomas Vander Stichele]

(Playing Devil's Advocate here)

> And I think that the xvidenc and
> ffenc_mpeg4 elements show that the presets are capable of providing a
> useful abstraction. And if people do not find them useful they of course
> don't need to use the preset files.

But is it that hard to make xvidenc and ffenc_mpeg4 just support the
same properties for the things you're interested in in your profile ?

Alternatively, why not implement something that the encoders support
straight out of the box ? Why add a layer on top instead of into the
elements ?

> > In short: we should concentrate on really capable encoding profiles, instead.
>
> Agreed, and that is part of the effort here. And I hope to be able to
> push them forward another step during GUADEC.

I, like Mike, was confused about what they were for based on the name.
I suggest not calling them encoder profile at all, because I suspect
pretty much 90% of people will think it's 'the thing they'll need to use
to encode for their psp/ps3/ipod/whatever'.

Also, it sounds like what you're trying to do is something that applies
to much more than encoders - I recall we talked in the past about having
ways to store and restore presets of element settings as a bunch
together, and that would make just as much sense for elements like
sources or converters, IMO.  Although I could understand if it's not
something you'd want to tackle if your focus is on Transmageddon right
now.  But it'd be nice if others could take it to a more generic level.

Thomas

--
what good are promises
if nobody honours them ?
--
Elisa - future TV today !
http://elisa.fluendo.com/

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Christian Fredrik Kalager Schaller]

On Tue, 2009-06-30 at 01:44 +0200, Thomas Vander Stichele wrote:
> (Playing Devil's Advocate here)
>
> > And I think that the xvidenc and
> > ffenc_mpeg4 elements show that the presets are capable of providing a
> > useful abstraction. And if people do not find them useful they of course
> > don't need to use the preset files.
>
> But is it that hard to make xvidenc and ffenc_mpeg4 just support the
> same properties for the things you're interested in in your profile ?

Well that is what I was told by the powers that be. My original code did
rely on all elements having the same property names, but I was told it
would be next to impossible to actually make that work for all possible
cases, and that I should instead look to use the preset system.

> Alternatively, why not implement something that the encoders support
> straight out of the box ? Why add a layer on top instead of into the
> elements ?
>
> > > In short: we should concentrate on really capable encoding profiles, instead.
> >
> > Agreed, and that is part of the effort here. And I hope to be able to
> > push them forward another step during GUADEC.
>
> I, like Mike, was confused about what they were for based on the name.
> I suggest not calling them encoder profile at all, because I suspect
> pretty much 90% of people will think it's 'the thing they'll need to use
> to encode for their psp/ps3/ipod/whatever'.

Well that is what the profiles are about. I have tried on the wiki to be very
clear to only use the word 'presets' to talk about these element specific files,
and only use the word 'profiles' in relation to the XML files we are
creating for the various devices:
http://gstreamer.freedesktop.org/wiki/DeviceProfile

> Also, it sounds like what you're trying to do is something that applies
> to much more than encoders - I recall we talked in the past about having
> ways to store and restore presets of element settings as a bunch
> together, and that would make just as much sense for elements like
> sources or converters, IMO.  Although I could understand if it's not
> something you'd want to tackle if your focus is on Transmageddon right
> now.  But it'd be nice if others could take it to a more generic level.
Well the preset system predates my effort and is already used in
Buzztard and there is a equalizer preset available also. So yes, the
preset applies to much more than encoders, but it is of course encoders
I am focusing on at the moment.

Christian


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

Michael Smith schrieb:

> On Thu, Jun 25, 2009 at 1:46 AM, Daniel G. Taylor<[hidden email]> wrote:
>  
>> Michael,
>>
>> On Tue, 2009-06-23 at 15:30 -0700, Michael Smith wrote:
>>    
>>> So to clarify:
>>>  - the profiles are ONLY to map some specific known profile names to a
>>> set of property values for a particular element, so that if you have
>>> two different encoder implementations (which both support the same
>>> basic semantics, but have different property names, or different
>>> units, etc.) you can set things up without knowing the specifics of
>>> the encoder.
>>>      
>> Correct, though it is also useful in the following scenario: if several
>> H.264 encoders exist in your GStreamer installation, then you can
>> request something like "video/x-h264 Baseline Profile" and GStreamer
>> would give you an H.264 encoder that supports that profile (it is
>> possible that one would support Baseline and Main, another support all
>> profiles, and yet another could be a highly optimized High Profile only
>> encoder). The point is to basically add feature information in a
>> standardized way to the various encoders that is easy to load as a
>> preset.
>>    
>
> This seems like a useful bit of functionality - but it'd be much
> better to be able to query this programatically from the element,
> rather than having to rely on someone having written appropriate
> preset files.
>
>
>
>  
>>> They're NOT for providing a drop-down of different encoding settings
>>> in your application, or anything like that. There are a number of
>>> major problems with trying to use them for that purpose (which is what
>>> I initially thought they were for). Your application still has to
>>> provide that layer entirely.
>>>      
>> However, they CAN be used for this purpose. Choosing a profile is a
>> useful action in many cases, especially when encoding for various
>> devices. My ultimate goal is of course to hide all this behind the
>> device profiles themselves as is currently done in Arista, but there's
>> no reason that Transmageddon can't let a user select profiles and
>> qualities based on these preset files.
>>    
>
> I thought so too originally, but there are problems with that: the
> presets don't have any i18n capabilities, for one.
>  

Presets are using GKeyfile and GKeyfiles are translatable.

Stefan

>  
>>> I think in practice what people want is an "encoding profile" that
>>> specifies things more completely - e.g. for audio, it might say
>>> "stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and
>>> have a name of "Medium quality Foo Audio" (this would need to be
>>> translateable somehow, but that's a different issue). You could
>>> provide a replacement profile with the same name using a different
>>> encoder, of course.
>>>      
>> This is what the device profiles are for, which internally will use the
>> encoder presets to select encoding profiles, qualities, etc. The preset
>> files are a necessary change before we start locking down a device
>> profile format which will result in giving you and others the profiles
>> you want to see.
>>    
>
> The device profiles are a much more important part of this. I think
> those are interesting. I don't think the presets help with this.
>
> The reason for separating the presets seems to be some idea that there
> will be many different encoders for every format, all using different
> configuration options. I simply don't believe that this is likely.
>
> I expect that every new encoder will either
>   a) be simple, and not have many configuration knobs - and those that
> it has will be fairly standard things like bitrate
> or
>   b) be substantially more complex, and a customised profile will be
> desirable to take advantage of the encoder's capabilities.
>
> Because of this, I do not see the benefit in separating the presets
> from the profiles - I think in all cases, either the preset isn't
> needed (because everything is standard) OR enough things will be
> different that a different encoder profile is needed. I also think
> that it's _generally_ going to be uncommon to have many different
> encoders.
>
> In short: we should concentrate on really capable encoding profiles, instead.
>
> Mike
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>  

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Stefan Sauer]

Michael Smith schrieb:

> On Tue, Jun 23, 2009 at 11:06 AM, Christian Fredrik Kalager
> Schaller<[hidden email]> wrote:
>  
>> Hi,
>> I have been working for a while on defining GStreamer level presets
>> based on the current plugin level preset system. The general document
>> for those presets can be found here:
>> http://gstreamer.freedesktop.org/wiki/PresetDesign
>>    
>
> After some discussion on IRC, I finally figured out what the presets
> are actually _for_ - I initially totally misunderstood.
>
> So to clarify:
>  - the profiles are ONLY to map some specific known profile names to a
> set of property values for a particular element, so that if you have
> two different encoder implementations (which both support the same
> basic semantics, but have different property names, or different
> units, etc.) you can set things up without knowing the specifics of
> the encoder.
>
> They're NOT for providing a drop-down of different encoding settings
> in your application, or anything like that. There are a number of
> major problems with trying to use them for that purpose (which is what
> I initially thought they were for). Your application still has to
> provide that layer entirely.
>  

In buzztard I use the presets like in the second case. Soft-synths and
effects have a sidebar with a list of setting. Thas also how e.g. the
equalizer plugin uses them.

one alternative for the presets in the encoder scenario would be gobject
interfaces for encoders. openmax il attempts to do that in a way by
specifying default properties each e.g. mpeg4 video encoder needs to have.

Stefan
>  

> In my opinion, this is not very helpful. In reality, if you have two
> different encoders, either:
>  - they support the same semantics, so making them use the same
> property names/values for that is simple.
>  - they support different things, so just mapping names/values/etc
> doesn't help you at all
>  
> On to some specifics about the presets you've proposed:
>  - Where you have things like "Quality High", you've just selected a
> bitrate. But, that only makes sense at a particular size of input
> (resolution/framerate/etc for video, number of channels, sample rate
> etc for audio). Why not just a preset called "Bitrate 128kbps"? That
> maps equally well to the underlying properties, but doesn't imply
> anything about quality - which is good, since the preset is _only_
> setting the bitrate, and actually doesn't have anything to do with
> quality.
>  - Some presets are designed to be applied along with others, some are
> mutually exclusive (e.g. for AAC, the profiles are mutually exclusive,
> but a profile and a bitrate can both be selected). But there's no
> information provided about which is which. So, an application just has
> to hardcode profile names, so this isn't in practice at all
> extensible.
>
>
> I think in practice what people want is an "encoding profile" that
> specifies things more completely - e.g. for audio, it might say
> "stereo, 44.1kHz, bitrate 128kbps, codec foo, container bar, etc", and
> have a name of "Medium quality Foo Audio" (this would need to be
> translateable somehow, but that's a different issue). You could
> provide a replacement profile with the same name using a different
> encoder, of course.
>
> Summary:
>  - I don't think the aims are clear.
>  - I don't think the current proposal works very well for what its
> aims are, OR for what people are likely to think its aims are.
>
> Mike
>
>
>
>  
>> My current set of .prs files can be found here:
>> http://cgit.freedesktop.org/~uraeus/transmageddon/tree/presets
>>
>> I think I have managed to sort out what should be in the files at this
>> point, including what kind of values makes sense and what kind of values
>> do not make sense. Even tried documenting those choices on the wiki
>> pages.
>>
>> Before I start committing these .prs files to the various GStreamer
>> modules I would like to ask people to take a look at them and the
>> current specification and let me know if people:
>> a) agree with the type of values I have choosen for the .prs files
>> b) agree with the actual values choosen for some of these values.
>> Especially the actual bitrates choosen for the Quality settings might
>> need some polishing (and maybe even more than 3 different options)
>>
>> These presets can be used independently, but I plan on using them as
>> part of the device level profiles, linked from the Preset page. But
>> those profiles are still in a flux and will most likely change a bit, so
>> please disregard that page for the time being or at least see it as a
>> work in progress.
>>
>> Christian
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>>    
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>  

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel