mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-28 12:41:05 +00:00
66 lines
3 KiB
Markdown
66 lines
3 KiB
Markdown
|
# Controller
|
|||
|
|
|
|||
|
|
The controller subsystem allows to automate element property changes. It
|
|||
|
|
works so that all parameter changes are time based and elements request
|
|||
|
|
property updates at processing time.
|
|||
|
|
|
|||
|
|
## Element view
|
|||
|
|
|
|||
|
|
Elements don’t need to do much. They need to: - mark object properties
|
|||
|
|
that can be changed while processing with GST\_PARAM\_CONTROLLABLE -
|
|||
|
|
call gst\_object\_sync\_values (self, timestamp) in the processing
|
|||
|
|
function before accessing the parameters.
|
|||
|
|
|
|||
|
|
All ordered property types can be automated (int, double, boolean,
|
|||
|
|
enum). Other property types can also be automated by using special
|
|||
|
|
control bindings. One can e.g. write a control-binding that updates a
|
|||
|
|
text property based on timestamps.
|
|||
|
|
|
|||
|
|
## Application view
|
|||
|
|
|
|||
|
|
Applications need to setup the property automation. For that they need
|
|||
|
|
to create a GstControlSource and attach it to a property using
|
|||
|
|
GstControlBinding. Various control-sources and control-bindings exist.
|
|||
|
|
All control sources produce control value sequences in the form of
|
|||
|
|
gdouble values. The control bindings map them to the value range and
|
|||
|
|
type of the bound property.
|
|||
|
|
|
|||
|
|
One control-source can be attached to one or more properties at the same
|
|||
|
|
time. If it is attached multiple times, then each control-binding will
|
|||
|
|
scale and convert the control values to the target property type and
|
|||
|
|
range.
|
|||
|
|
|
|||
|
|
One can create complex control-curves by using a
|
|||
|
|
GstInterpolationControlSource. This allows the classic user editable
|
|||
|
|
control-curve (often seen in audio/video editors). Another way is to use
|
|||
|
|
computed control curves. GstLFOControlSource can generate various
|
|||
|
|
repetitive signals. Those can be made more complex by chaining the
|
|||
|
|
control sources. One can attach another control-source to e.g. modulate
|
|||
|
|
the frequency of the first GstLFOControlSource.
|
|||
|
|
|
|||
|
|
In most cases GstControlBindingDirect will be the binding to be used.
|
|||
|
|
Other control bindings are there to handle special cases, such as having
|
|||
|
|
1-4 control- sources and combine their values into a single guint to
|
|||
|
|
control a rgba-color property.
|
|||
|
|
|
|||
|
|
## TODO
|
|||
|
|
|
|||
|
|
* control-source value ranges - control sources should ideally emit values
|
|||
|
|
between \[0.0 and 1.0\] - right now lfo-control-sources emits values
|
|||
|
|
between \[-1.0 and 1.0\] - we can make control-sources announce that or
|
|||
|
|
fix it in a lfo2-control-source
|
|||
|
|
|
|||
|
|
* ranged-control-binding - it might be a nice thing to have a
|
|||
|
|
control-binding that has scale and offset properties - when attaching a
|
|||
|
|
control-source to e.g. volume, one needs to be aware that the values go
|
|||
|
|
from \[0.0 to 4.0\] - we can also have a "mapping-mode"={AS\_IS,
|
|||
|
|
TRANSFORMED} on direct-control-binding and two extra properties that are
|
|||
|
|
used in TRANSFORMED mode
|
|||
|
|
|
|||
|
|
* control-setup descriptions - it would be nice to have a way to parse a
|
|||
|
|
textual control-setup description. This could be used in gst-launch and
|
|||
|
|
in presets. It needs to be complemented with a formatter (for the preset
|
|||
|
|
storage or e.g. for debug logging). - this could be function-style:
|
|||
|
|
direct(control-source=lfo(waveform=*sine*,offset=0.5)) or gst-launch
|
|||
|
|
style (looks weird) lfo wave=sine offset=0.5 \! direct .control-source
|