Use the pad as object for logging to get more context. Use
gst_pad_store_sticky_event() instead of sending the event. This avoids a warning
as here the pad is not yet linked and we actually don't want to send anyway.
It was used for pad-alloc in 0.10 but currently is completely unused
and not necessary. All pad access is protected by the tee object lock
and keeping another reference to the current pad.
Add private replacements for deprecated functions such as
g_mutex_new(), g_mutex_free(), g_cond_new() etc., mostly
to avoid the deprecation warnings. We can't change most of
these in 0.10 because they're part of our API and ABI.
Add a new event flag for sticky events so that multiple events of that type can
be stored on a pad at the same time. Change the _get_sticky_event() function to
loop over the multiple events of a type.
Change the foreach function to make it possible to removed and modify the sticky
events on a pad.
Use an variable size array now to store the events. This could later be
optimized some more.
Add the pad mode to the activate function so that we can reuse the same function
for all activation modes. This makes the core logic smaller and allows for some
elements to make their activation code easier. It would allow us to add more
scheduling modes later without having to add more activate functions.
Remove the getcaps function on the pad and use the CAPS query for
the same effect.
Add PROXY_CAPS to the pad flags. This instructs the default caps event and query
handlers to pass on the CAPS related queries and events. This simplifies a lot
of elements that passtrough caps negotiation.
Make two utility functions to proxy caps queries and aggregate the result. Needs
to use the pad forward function instead later.
Make the _query_peer_ utility functions use the gst_pad_peer_query() function to
make sure the probes are emited properly.
Always forward all events in the default handler. Previously it used to not
forward caps events by default. It makes more sense to forward the caps events,
if the element is interested in the caps, it will implement an event handler to
retrieve the caps and then it can decide to forward or not. If the element has
no event handler, it probably just doesn't care about caps and it probably is
also not going to modify the data in a way that needs a caps change.
When releasing the request pad, first remove it from the element and then
deactivate it. If we do it the other way around, a gst_pad_push on the element
might return wrong-state before we had a chance to detect the removed pad in the
chain function.
Remove pad_alloc and all references. This can now be done more efficiently and
more flexible with the ALLOCATION query and the bufferpool objects. There is no
reverse negotiation yet but that will be done with an event later.
1) We need to lock and get a strong ref to the parent, if still there.
2) If it has gone away, we need to handle that gracefully.
This is necessary in order to safely modify a running pipeline. Has been
observed when a streaming thread is doing a buffer_alloc() while an
application thread sends an event on a pad further downstream, and from
within a pad probe (holding STREAM_LOCK) carries out the pipeline plumbing
while the streaming thread has its buffer_alloc() in progress.
Make sure property names passed to g_object_notify() are in the canonical form
(ie. "last-message" not "last_message"), so that g_param_spec_pool_lookup()
doesn't have to do strdup/canonicalize/free for every single notify call.
This only applies when building against older GLib versions (< 2.26).
