[Bug 766898] player: Add a message queue API in addition to the signals

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766898

--- Comment #7 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Stephan Hesse from comment #6)
> Understood, makes sense.
> 
> So then the idea would be: 
> 
> - position, duration and other values of arbitrary/transient character can
> be queried from the API at any moments
> 
> - messages get created with data that is queried on creation of the message
> from within the pipeline, using the exact same mechanism as the
> corresponding API methods (to read position/duration etc)
> 
> Will add some custom functions to create those position/duration messages
> with the values obtained from the pipeline instead of caching them (as for
> error and warning).
> 
> We may still be able to use the current _from_state method for messages that
> actually can get created from the state solely.

It's probably simpler to not have a separate function for this but just create
the structures ad-hoc where they're needed, just like in e.g. gstmessage.c. If
you get rid of the GValue juggling, it's one line per message creation :)

> And our next step would now be (re)moving the signal stuff from this file
> and building a proxy object from signal-based API as you had suggested. 

Yes, and get rid of the signal dispatcher

> We probably also need to think about how to deal with an application that
> would not consume from the bus, how to avoid filling memory with more and
> more data structures that are not being consumed/unrefed at some point.
> Maybe I am still a bit unfamiliar with GstBus. How is this usually done?

They are accumulating, and application will have to handle messages from the
bus or set the bus to flushing.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.