GNOME Bugzilla – Bug 626550
More powerful preset/profile mechanism needed
Last modified: 2018-05-07 06:35:25 UTC
Our presets, as in GstPreset, seem to be not powerful enough for many use cases. In fact nobody seems to use them at all ;) We probably need something that could cover multiple elements (e.g. a videobalance followed by a black-white element), something that could hardcode properties but could also export new properties (for combinations of element properties or range changes), etc. This could then be used in cheese or pitivi for the effects for example. Currently there's either the way to work with the elements based on the element details and additional external metadata or gnome-video-effects: http://git.gnome.org/browse/gnome-video-effects/tree/effects The best would be, if this could also cover something like the profiles of gst-convenience: http://git.collabora.co.uk/?p=user/edward/gst-convenience.git;a=tree;f=gst-libs/gst/profile
(In reply to comment #0) > Our presets, as in GstPreset, seem to be not powerful enough for many use > cases. In fact nobody seems to use them at all ;) > I actually use them for buzztard. They would also fit ladspa / lv2 if there would be defined preset locations. Having presets as in pipeline fragments with hardcoded parameters and specifically selected "editable" parameters would be nice for certain apps. I think jokosher has something simillar for groups of ladspa effects. Ultimately we have a bin, that can instantiate them.
Youness has written something to do kind of presets (but abstraction all of the gst work and calling them filters). And with a manager to be able to add-remove them dynamically without having to deal with pad blocking, etc. Code (see the files with filter in the name): http://git.collabora.co.uk/?p=user/kakaroto/farsight2.git;a=tree;f=gst-libs/gst/farsight;hb=fsu
I like this strategy as well: http://abock.org/2007/01/06/audio-profile-configuration-for-the-masses
Yes, I liked (and still like) Aaron's sexpr language too. Something like this should be part of the powerful presets for property mapping and conditional use of elements and stuff like that.
One (easy to fix) shortcoming of Aaron's presents is that element-names are hardcoded. For encoding/transcoding it would be better to put media-types there so that elements can be taken from the registry. That helps picking harware accelerated elements where available. That still leaves the issue with mapping the element properties (bug #118142). We'll somehow have to start small and extend the approach. It is all quite complicated. And maybe we need to consider having separate solutions for effect-templates and for encoding/transcoding presets for now.
I like the idea of having more powerful Presets. I think the most useful thing we have right now is the .effect file format from the gnome-video-effects package. But I think that format should be extended to allow for user-configuration. I'd like to see some way to define a range of values that can be used for elements so users can configure them with a slider, or checkbox or something similar, and also having some kind of specific presets. Here's a draft of how we could enhance the .effect file format, it might be a good start for these extended presets : --------------------------------- [Effect] Encoding=UTF-8 Name=[The human readable effect name] Name[LangCode]=[The translated human readable effect name] ... Comment=[Description of the effect (tooltip?)] Comment[LangCode]=[Translation of the description of the effect] ... Category=[The category of your effect, e.g. "Colors".] PipelineDescription=[A valid GStreamer pipeline] [Configuration] Type=[type of configuration, eg."bool", "int", etc..] Min=[minimal allowed value] Max=[maximum allowed value] Element=[name of the element to configure] Property=[property name to modify for the element] [Configuration] .... [Preset] Name=[name of the preset] Element[Property]=[value for <Property> on <Element>] Element2[Property2]=[value for <Property2> on <Element2>] ... --------------------------------- This way, it would be possible to allow user configuration of specific properties while keepign the configuration in the effect's purpose (example, changing the hue/saturation of the Hulk effect to change the 'how much green' but keep the values range inside the right range so that the color doesn't change from green to something else). This is just a draft, but I'd like to find some way to link properties together, for example, if property1 is in the range [x1, y1], then the range of property2 will be [a1, b1], if it's in the range of [x2, y2], then the range of property2 will [a2, b2]. This should allow for something like a rotating zoom where a single slider would affect two properties on two different elements at the same time. If someone has a suggestion to achieve this, let me know!
see also comments in bug #626533, which is probably a duplicate of this
Unlike other parts of GStreamer, this is a very user-centered feature. Accordingly, it would make sense to consider the needs of user interfaces in its design. In theory all you need are lists of user-visible properties from which you can generate form-like interfaces. However, we have tried this sort of thing in PiTiVi and users have reacted against it pretty violently. Basically, auto-generated UI looks like rubbish. You're confined to very linear layouts, and often this just doesn't work. It would be helpful for encoding presets to agree on a common set of configurable properties so that UI can present these more consistently (e.g. if you're going to have a quality setting, it should always be called "quality", and the values should be interpreted in a consistent fashion). This would make the core properties easier to incorporate into a static dialog. For encoding, the relevant information to the user is (more-or-less): - where is the media going - subjective qualities of the media they are processing (i.e. is the content they have suitable for this preset or not?) the target for the media - quality vs. output size - quality vs. rendering speed Basically I'd like like to be able to provide users with: - A consistent set of controls for setting the output format and quality - estimates of rendering time and speed - preview of the output Anything we can do in the preset system to support this is a step in the right direction.
Brandon, could we separate the preset mechanism and more hints for generated UIs. In buzztard I am creating UIs for gstreamer effects (native, ladspa, buzzmachines). I'd like to have more flags/hints on elements to be able to generate better UIs as well, but I think it is a different issue that this one.
I bring it up because in the original posting, Sebastian mentioned this: > The best would be, if this could also cover something like the profiles of > gst-convenience: > http://git.collabora.co.uk/?p=user/edward/gst-convenience.git;a=tree;f=gst- > libs/gst/profile It's not clear to me that the feature set really does overlap though. I'm definitely not suggesting that we embed UI descriptions in the presets.
Any progress on this? Edward, Stefan?
For my use cases GstPresets work fine.
From reading the whole ticket, it seems we all agree that something better than presets is needed but nobody is really sure how that would look like... and in the last 5 years nobody did anything in this direction either. So I would suggest to close this until someone actually has a use-case that needs it, and then the design and implementation around this use-case can start.