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 _______________________________________________ gnome-multimedia mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-multimedia
