GNOME Bugzilla – Bug 697327
RFC: syncing messages with rendering
Last modified: 2018-11-03 12:17:48 UTC
Right now we don't offer a good solution with the existing level and spectrum elements. They post a message with the analysis data containing a timestamp with the presentation-time. Scheduling the on-screen update of a widget or a graph is left to the developer. And is actually complicated and inefficient to do. This is what I do right now in buzztard: // listen for message::element on the bus // in the signal handler: // get pts from the message pts += gst_element_get_base_time (level); GstClockId clock_id = gst_clock_new_single_shot_id (clock, pts); gst_clock_id_wait_async (clock_id, on_delayed_analyzer_change, message, NULL); // on_delayed_analyzer_change g_idle_add_full (G_PRIORITY_HIGH, on_delayed_idle_analyzer_change, data, NULL); // on_delayed_idle_analyzer_change gtk_level_meter_set (....) gst_message_unref (message); Here the control-flow goes from streaming thread (level) via bus to the application's main thread. Then a new handler is added to the clock (for each message). This gets fired from the streaming thread of the sink. Thus I marshal things back to the main thread via g_idle_add. (I could probably skip the first context marshaling by using a sync message.) Using a sink-message in the element is not good enough, as this will only sync with dataflow, but not rendering. Now a few proposals. 1) Add a boolean "post-sink-message" property to level/spectrum. Add the PTS to the sink-message. In basesink check if the message has a PTS, if not post immediately from the sink (as now). If it has a PTS, dispatch to render(). 2) Add a boolean "sync-message" property to level/spectrum. If set the element will do the gst_clock_new_single_shot_id() + gst_clock_id_wait_async() before posting the message. Any opinions, other ideas?
I'd add a timestamp to the sink-message event and let the sink handle all that
-- 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/36.