GNOME Bugzilla – Bug 616173
[RFC] GstFormat support in GstController
Last modified: 2016-05-14 19:02:09 UTC
Right now the element that implements gst controller uses gst_object_sync_values(object, timestamp). For most elements that makes sense, but not for live sources. Their timestamps are not predictable and those would rather work in terms of buffers (frames). Some loud thinking: 1.) We could add a gboolean gst_controller_set_format(GstController *, GstFormat *) (plus the getter). Apps would still prepare the controlchanges in time values. When the element calls gst_object_sync_values() we would like to convert from controller format to time. That would have been much easier if gstcontroller would have been an interface :/ 2.) Maybe even apps would like to use frames/buffers for live sources. If neccesary the apps might also be able to convert (then conversion would be when preparing the controlchanges). Then the question is how to probe on the app side what fromat the element prefers.
There is a patch in Bug #622390 for v4l2src to just ignore the life-timestamps, but use a separate fram-interval counter for the controller. Sees to work okay and has the advantage that we can e.g. not advance the controller on bad-frames.
Or maybe just add a function to add an offset to GstController, which is then subtracted when syncing the values?
You mean live-sources would do e.g. gst_controller_set_timestamp_offset(GstController, GstClockTime) and use the basetime as the offset? That would indeed solve the live-src timestamp issue. gst_object_sync_values() can take that into account and this way the overhead is rather minimal. Will try it.
Is this still something you want or need ?
Not personally. v4l2src is a live src and has controllable properties, if this comes up for other live elements we can at least implement it in the same way.