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

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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel