Thi introduces new APIs to post a `DEVICE_CHANGED` message on the
bus so the application is notifies when a device is modified. For
example, if the "defaultness" of a device was changed or any property
that can be changed at any time. Atomically changing the device
object notifying that way allow us to abtract away the internal threads.
New APIS:
- gst_message_new_device_changed
- gst_message_parse_device_changed
- gst_device_provider_device_changed
The caller might pass arbitrary data here that caused the error, and
trying to set invalid UTF-8 in a GstStructure causes it to be not set at
all. Later when trying to parse it, the field will not exist and the
return value will point to invalid memory. Prevent this by storing NULL
instead.
Also print a g_warning(), the caller should never ever do this to begin
with.
Redirection messages are already used in fragmented sources and in
uridecodebin, so it makes sense to introduce these as an official message
type.
https://bugzilla.gnome.org/show_bug.cgi?id=631673
gst_structure_id_get() returns a new reference so the returned object is
actually (transfer full).
The unit tests was already unreffing the objects.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
gst_structure_id_get() returns a new reference so the returned device is
actually (transfer full).
The code using this API was already correct but the code example in
comments was not.
https://bugzilla.gnome.org/show_bug.cgi?id=768776
Be notified in the application thread via bus messages about
notify::* and deep-notify::* property changes, instead of
having to deal with it in a non-application thread.
API: gst_element_add_property_notify_watch()
API: gst_element_add_property_deep_notify_watch()
API: gst_element_remove_property_notify_watch()
API: gst_message_new_property_notify()
API: gst_message_parse_property_notify()
API: GST_MESSAGE_PROPERTY_NOTIFY
https://bugzilla.gnome.org/show_bug.cgi?id=763142
Revive message in dispose handler before we signal the bus thread,
otherwise the bus thread might be woken up and unref the message
before we had a chance to revive it yet.
Async message delivery (where the posting thread gets blocked
until the message has been processed and/or freed) was pretty
much completely broken.
For one, don't use GMutex implementation details to check
whether a mutex has been initialized or not, esp. not
implementation details that don't hold true any more with
newer GLib versions where atomic ops and futexes are used
(spotted by Josep Torras). This led to async message
delivery no longer blocking with newer GLib versions on
Linux.
Secondly, after async delivery don't free mutex/GCond
embedded inside the just-freed message structure.
Use a new (private) mini object flag to signal GstMessage
that the message being freed is part of an async delivery
on the bus so that the dispose handler can keep the message
alive and the bus can free it once it's done cleaning up
stuff.
They are very confusing for people, and more often than not
also just not very accurate. Seeing 'last reviewed: 2005' in
your docs is not very confidence-inspiring. Let's just remove
those comments.
All streams that have the same group id are supposed to be played
together, i.e. all streams inside a container file should have the
same group id but different stream ids. The group id should change
each time the stream is started, resulting in different group ids
each time a file is played for example.
