[gst-devel] GstController: To sync or not to sync values

Sebastian Dröge slomo at circular-chaos.org
Fri May 18 08:53:05 CEST 2007


Hi,
as Wim started yesterday on IRC there seems to be some ideas for the
GstController that are not written down anywhere yet, using the
_get_value_array* functions of the controller.

Wim, could you please summarize your ideas and what you want to achieve
with doing stuff that way?


Stefan and me discussed in the last days about how to make the _sync()
functions a bit more useful and he also wrote some mails about it to the
list, nobody answered them though ;)

Then plan is to give the controller a way to suggest timestamps where
syncs would make most sense, i.e. exactly on trigger timestamps if the
trigger interpolation mode is used. Also the control-rate property would
be used by this to guarantuee that at least every control-rate
nanoseconds a sync is done where the control-rate a) has a sane default
value and b) could be set properly by the tempo interface that Stefan
plans.

To make subdividing the processing loop by elements a bit easier we
planned to add this subdividing and syncing to the base classes, i.e.
BaseTransform, BaseSrc. This was also mentioned in his last mail about
this to the list and nobody noticed...

Now there is another approach to get sane values, which is probably what
you want: Having sample accurate values given by the controller by not
using syncing but requesting n values, starting from timestamp x with a
step size of 1/sample-rate nanoseconds. In general a good idea, sample
accurate values are always nice (although they're not really needed for
the stuff Stefan tested). The only three problems I see with this method
are a) the imense amount of data that is created, b) the bypassing of
the GObject properties that these values actually represent and c) it's
not easily possible to enforce that triggers are done as the trigger
timestamp might be between two samples.

For b) one could probably just sync the GObject values at the beginning
and/or the end of the processing loop. For c) one could use a
combination with the sync approach: The processing loop would first be
subdivided as explained above and then the elements would ask for each
of this subbuffers sample accurate values from the controller (and
having the value for the first sample maybe with a slightly different
timestamp than it is to exactly hit the trigger timestamps).

What do you think about this combination of approaches? And please try
to explain what your idea of the controller is and what you need it for,
especially why you _need_ sample accurate values :)

Bye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070518/5722d111/attachment.pgp>


More information about the gstreamer-devel mailing list