aggregator: For the start time selection, only set the segment position

segment.time and segment.start can stay the same, and were always the same
before anyway because of a mistake.

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

aggregator: Don't forward QOS events to sinkpads that had no buffer yet

Otherwise they will receive a QOS event that has earliest_time=0 (because we
can't have negative timestamps), and consider their buffer as too late

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

aggregator: Keep at least two buffers in the queue in live mode

When in live mode, the queue needs to hold the currently processed
buffer and one more at least.

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

aggregator: Document that get_next_time() should return running time

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

aggregator: Also ignore start-time on seek from gst_element_send_event()

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

tests: Add test for seeking live pipelines

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

tests: Make source live to re-enable aggregator timeout tests

The live mode is only enabled if one of the sources if live.

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

aggregator: Queue "latency" buffers at each sink pad.

In the case where you have a source giving the GstAggregator smaller
buffers than it uses, when it reaches a timeout, it will consume the
first buffer, then try to read another buffer for the pad. If the
previous element is not fast enough, it may get the next buffer even
though it may be queued just before. To prevent that race, the easiest
solution is to move the queue inside the GstAggregatorPad itself. It
also means that there is no need for strange code cause by increasing
the min latency without increasing the max latency proportionally.

This also means queuing the synchronized events and possibly acting
on them on the src task.

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

aggregator: Default to "zero" start time selection mode as documented

aggregator: Ignore the "first" mode if the segment not a time segment

aggregator: Add property to select how to decide on a start time

Before aggregator based elements always started at running time 0,
now it's possible to select the first input buffer running time or
explicitly set a start-time value.

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

aggregator: Query the peer latency again on the next opportunity after a pad was added or removed

Adding a pad will add a new upstream that might have a bigger minimum latency,
so we might have to wait longer. Or it might be the first live upstream, in
which case we will have to start deadline based aggregation.

Removing a pad will remove a new upstream that might have had the biggest
latency, so we can now stop waiting a bit earlier. Or it might be the last
live upstream, in which case we can stop deadline based aggregation.

aggregator: add a convenience macro to get the source pad

Easier than casting or acessing the parent everywhere

aggregator: Document that the latency is in ns

aggregator: Push EOS on error return.

Before shutting down the srcpad task due to a
downstream error, push an EOS to give downstream
a chance to shut down somewhat cleanly.

aggregator: document gap handling behavior

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

aggregator: drop stale white space at warning

aggregator: fix typo in test suite

aggregator: add gap event handling unit test

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

aggregator: implement gap handling

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

aggregator: Unify downstream flow return and flushing

Also means that having a non-OK downstream flow return
wakes up the chain functions.

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

aggregator: Flushing is always in pad lock, no need to atomics

The usage of atomics was always doubtful as it was used to release a
GCond

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

aggregator: Reset pending_eos on pad flush

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

aggregator: Unify code to set a pad flushing

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

aggregator: Query latency on first incoming buffer.

And keep on querying upstream until we get a reply.

Also, the _get_latency_unlocked() method required being calld
with a private lock, so removed the _unlocked() variant from the API.
And it now returns GST_CLOCK_TIME_NONE when the element is not live as
we think that 0 upstream latency is possible.

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

aggregator: Be more aggressive with invalid replies to our latency query

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

aggregatory: don't redefine GST_FLOW_CUSTOM_SUCCESS

aggregator: Use standard upstream latency querying logic

The same functionality is duplicated in the default latency querying
now.

aggregator: Use src_lock to protect latency related members

One has to use the src_lock anyway to protect the min/max/live so they
can be notified atomically to the src thread to wake it up on changes,
such as property changes. So no point in having a second lock.

Also, the object lock was being held across a call to
GST_ELEMENT_WARNING, guaranteeing a deadlock.

aggregator: Remove untrue comment

aggregator: Don't try to push tags while flush seeking

The downstream segment could have been flushed already, so
need to re-send the segment event before re-sending the tags.

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

aggregator: Use the sinkpads iterator directly to query upstream latencies

While gst_aggregator_iterate_sinkpads() makes sure that every pad is only
visited once, even when the iterator has to resync, this is not all we have
to do for querying the latency. When the iterator resyncs we actually have
to query all pads for the latency again and forget our previous results. It
might have happened that a pad was removed, which influenced the result of
the latency query.

aggregator: Move gst_aggregator_get_latency_unlocked() a bit

It was between another function and its helper function before, which was
confusing when reading the code as it had nothing to do with the other
functions.

aggregator: Fail the latency query if one of the upstream queries fails

aggregator: Document locking order

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

aggregator: Rename confusinly named SRC_STREAM_LOCK macros to SRC_LOCK

This will match the name of the lock itself. It is also not a stream
lock as it not recursive and not held while pushing.

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

aggregator: Rename confusingly named stream lock to flush lock

This lock is not what is commonly known as a "stream lock" in GStremer,
it's not recursive and it's taken from the non-serialized FLUSH_START event.

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

aggregator: Fix macro indendation

Changes no code

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

aggregator: drop GAP events until we handle them properly

aggregator: use new gst_aggregator_pad_drop_buffer()

aggregator: add gst_aggregator_pad_drop_buffer()

steal_buffer() + unref seems to be a wide-spread idiom
(which perhaps indicates that something is not quite
right with the way aggregator pad works currently).

aggregator: only post latency message if anything changed

Perhaps we should check for element state as well and
only post it if in PLAYING state.

Improve and fix LATENCY query handling

This now follows the design docs everywhere, especially the maximum latency
handling.

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

aggregator: Pause srcpad task on flow errors

Otherwise we will call the task function over and over again until
upstream finally handled the flow return and shuts us down.

aggregator: Streamline latency calculations

Min latency can never be invalid, latency property can never be invalid
either. So no need to check for all these things in various places.

aggregator: If upstream has no max latency but the subclass has, take the subclass max latency

aggregator: Fix min>max latency error check

We have to include the upstream latency, our own latency and the subclass
latency in the calculations.

FIXME: This is still not entirely correct

aggregator: Don't add the latency property to the max latency

It has no meaning for the max latency and is only used to increase the min
latency.

aggregator: Cleanup locking around AggregatorPad flush related fields

And document the locking

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

aggregator: keep chain functions as dumb as possible.

+ A pad chain function has no business checking other pads,
  that's what the aggregate thread is for.

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

aggregator: More fixes around locking when accessing protected private fields

In some more places we were accessing GstAggregator->segment
and GstAggregator->seqnum without holding the GST_OBJECT_LOCK

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

aggregator: Make the PAD_LOCK private

Instead of using the GST_OBJECT_LOCK we should have
a dedicated mutex for the pad as it is also associated
with the mutex on the EVENT_MUTEX on which we wait
in the _chain function of the pad.

The GstAggregatorPad.segment is still protected with the
GST_OBJECT_LOCK.

Remove the gst_aggregator_pad_peak_unlocked method as it does not make
sense anymore with a private lock.

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

aggregator: Hide GstAggregatorPad buffer and EOS fileds

And add a getter for the EOS.

The user should always use the various getters to access
those fields

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

aggregator: Document locking of GstAggregatorPrivate members

Most of them are protected by the object lock, specify
which ones use a different lock.

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

aggregator: Document how the segment is protected

Document that it can only be accessed with the object lock.

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

aggregator: Protect all latency related members with the object lock

The locking was not consistent, now consistently use the object lock.

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

aggregator: Document locking for gst_aggregator_get_latency_unlocked()

Renamed it to _unlocked() to make it clear.

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

aggregator: Protect the srcpad caps negotiation with the stream lock

Instead of adding another lock, use the srcpad stream lock, which is already
taken anyway to push out the new caps if needed.

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

aggregator: Protect the tags with the object lock

The tags related variables were sometimes protected, sometimes not and
sometimes atomic. Put them all under the object lock.

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

aggregator: Consistenly lock the flow_return state

Use the object's lock to protect it.

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

aggregator: Consistently lock some members

Some members sometimes used atomic access, sometimes where not locked at
all. Instead consistently use a mutex to protect them, also document
that.

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

aggregator: Protect exported pad members with the pad's object lock

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

aggregator: Replace event lock with pad's object lock

Reduce the number of locks simplify code, what is protects
is exposed, but the lock was not.

Also means adding an _unlocked version of gst_aggregator_pad_steal_buffer().

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

aggregator: Protect data with the same mutex as GCond

Whenever a GCond is used, the safest paradigm is to protect
the variable which change is signalled by the GCond with the same
mutex that the GCond depends on.

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

aggregator: Nitpick spacing/punctuation in debug logging

aggregator: Remove pointless atomic

It is only modified from the streaming thread

aggregator: Fix query leak

aggregator: Print jitter from clock waiting in the debug logs

aggregator: don't use iterator when setting flush pending on pads

aggregator: check if pads are ready more efficiently

No need to use an iterator for this which creates a temporary
structure every time and also involves taking and releasing the
object lock many times in the course of iterating. Not to mention
all that GList handling in gst_aggregator_iterate_sinkpads().

aggregator: name vfunc arguments consistently

aggregator: add g-i transfer and scope annotations

aggregator: register names of iterate_sinkpads functions with debug system

aggregator: reduce debug messages for taking/releasing logs to TRACE level

Don't spam debug log with this stuff.

aggregator: move property member into private structure

Our locking (or lack thereof) while accessing this also
looks generally quite dodgy.

aggregator: remove empty dispose function

aggregator: give private functions namespace prefix

Especially the GST_DEBUG_FUNCPTR ones.

aggregator: fix up some docs comments in header

aggregator: remove now-unused system clock member

aggregator: make GstAggregatorPadForeachFunc take an GstAggregatorPad

aggregator: bring start/stop vfunc semantics in line with other baseclasses

Sub-class should not have to chain up to GstAggregator's start/stop
vfuncs, same as in GstBaseSrc, GstBaseSink, GstBaseTransform etc.

aggregator: remove pointless GST_DEBUG_FUNCPTR

Not useful for GObject vfuncs.

aggregator: remove duplicate pad parent_class variable

G_DEFINE_TYPE already provides one, just need to use it.

aggregator: add _CAST() variants for cast macros

aggregator: make padding larger

Esp. the class structures, can't have enough
spare space for virtual functions.

aggregator: Log to the pad instead of the element

More correct way of doing the same thing as before

aggregator: Make sure that the minimum latencies are never GST_CLOCK_TIME_NONE

aggregator: Wait for the minimum latency, not the maximum

The minimum latency is the latency we have to wait at least
to guarantee that all upstreams have produced data. The maximum
latency has no meaning like that and shouldn't be used for waiting.

aggregator: Clamp the min latency at the max if it's greater

aggregator: Print the sinkpad name while logging latency queries

Very useful while debugging.

aggregator: Take the stream lock when iterating sink pads

When iterating sink pads to collect some data, we should take the stream lock so
we don't get stale data and possibly deadlock because of that. This fixes
a definitive deadlock in _wait_and_check() that manifests with high max
latencies in a live pipeline, and fixes other possible race conditions.

aggregator: Don't leak flush-start events

aggregator: Also change the default latency to 0, not just the minimum

aggregator: Fix docs and default value of the latency property

aggregator: Also include the subclass latency in the result of the latency query

aggregator: Post a latency message if the value of the latency property changes

aggregator: Wake up the src thread after handling a latency query

Due to changed latencies or changed live-ness we might have to
adjust if we wait on a deadline at all and how long.

aggregator: Don't count the number of times we need to wake up but instead check all conditions for waiting again

This simplifies the code and also makes sure that we don't forget to check all
conditions for waiting.

Also fix a potential deadlock caused by not checking if we're actually still
running before starting to wait.

aggregator: Add function to allow subclasses to set their own latency

For audiomixer this is one blocksize, for videoaggregator this should
be the duration of one output frame.

aggregator: Add a timeout parameter to ::aggregate()

When this is TRUE, we really have to produce output. This happens
in live mixing mode when we have to output something for the current
time, no matter if we have enough input or not.