[gst-devel] GStreamer presets (feedback requested)

[Daniel G. Taylor]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20090625/2cdc3e5a/attachment.pgp>