After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 697327 - RFC: syncing messages with rendering
RFC: syncing messages with rendering
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-05 10:54 UTC by Stefan Sauer (gstreamer, gtkdoc dev)
Modified: 2018-11-03 12:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stefan Sauer (gstreamer, gtkdoc dev) 2013-04-05 10:54:10 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?
Comment 1 Sebastian Dröge (slomo) 2013-04-06 07:42:02 UTC
I'd add a timestamp to the sink-message event and let the sink handle all that
Comment 2 GStreamer system administrator 2018-11-03 12:17:48 UTC
-- 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.