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

[Stefan K. <en...@ho...>]

Michael Smith schrieb:
> On Thu, Jun 25, 2009 at 1:46 AM, Daniel G. Taylor<da...@pr...> 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
> gst...@li...
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>