GNOME Bugzilla – Bug 741427
RFC: gst-launch/gst-inspect support for presets
Last modified: 2018-11-03 12:24:45 UTC
Hi, gst-inspect could list the preset names if an element implements the preset iface. gst-launch could support a 'special' property called "@preset" to load a preset. e.g. gst-launch uridecodebin uri="..." ! equalizer @preset="disco" ! ... The rational for "@preset" is that it would not clash with other properties. Better ideas are welcome. if it sounds like a plan, I have a xmas vacation project :)
+1 for gst-inspect showing the names. Not a fan of that special @preset thing. I don't see why we need to hack around the lack of interfaces support in gst-launch for this particular interface. You could add a "preset" property to GstPreset and all GstPreset-using elements, although that would probably not be 100% backwards-compatible. But then, is anyone using the interface outside of our trees?
Created attachment 292748 [details] [review] gst-inspect: print preset names
Tim, if we'd add a 'preset' property, every element would need to implement it. And that just in order to support gst-launch. Apps would use the preset iface. Secondly, there is some risk that an element already has a property called 'preset' :/ To my knowledge we just have the equalizer and freeverb supporting presets. Right now I am proposing in #611689 to also implement the preset iface. For freeverb I never submitted them (will do that right away). Lots of encoders have the preset iface added, but no one added a preset file so far. Please also note that my proposal of @preset was not meant to hack around the lack of interfaces support in gst-launch, quite the contrary. If we want to support e.g. the preset iface in gst-launch, we need a syntax for it, so that the parser can match on it. Better ideas for the syntax are welcome. I proposed @preset as some command-line tools use this notation for commandline parameter files and I thought this metaphor matches quite nicely to what presets are for element-properties.
http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/parse/parse.l#n65 properties are set as _identifier [[:alnum:]_][[:alnum:]\-_%:]* _char ("\\".)|([^[:space:]]) _string {_char}+|("\""([^\"]|"\\\"")*"\"")|("'"([^']|"\\\'")*"'") _assign [[:space:]]*"="[[:space:]]* _assignment {_identifier}{_assign}{_string} for presets I'd add: _preset @preset _preset @preset{_assign}{_string} + the code to handle handle it. Any better ideas?
Created attachment 293471 [details] [review] parse: add support for presets Can be tested as: gst-launch-1.0 audiotestsrc wave=ticks ! freeverb @preset="cathedral" ! pulsesink gst-launch-1.0 audiotestsrc wave=ticks ! freeverb @preset="engine room" ! pulsesink We could simplify the syntax: ... ! freeverb @"cathedral" ! ... If we have consensus on the syntax, I'll update the man-page for gst-launch and add tests.
The x264enc element has some presets now, allowing to select a H.264 profile. Commandline support to help testing those would be welcome!
For the gst-inspect aspect: getting the list of presets, as is the case with 1.6.1, is nice, but would be much more useful if it printed the property values with them. That would even provide an interim solution to the use of presets in gst-launch until an interface is agreed upon, by allowing to cut'n'paste the preset contents into the gst-launch CLI :)
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/86.