Re: [gst-devel] GStreamer presets (feedback requested)

[Michael Smith <msmith xiph org>]

On Thu, Jun 25, 2009 at 1:46 AM, Daniel G. Taylor<dan programmer-art org> 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