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.

tests: fix aggregator unit test after property renaming

aggregator: Some minor cleanup

aggregator: make the src pad task drive the pipeline for live pipelines

This removes the uses of GAsyncQueue and replaces it with explicit
GMutex, GCond and wakeup count which is used for the non-live case.

For live pipelines, the aggregator waits on the clock until either
data arrives on all sink pads or the expected output buffer time
arrives plus the timeout/latency at which time, the subclass
produces a buffer.

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

tests/aggregator: Use correct type when setting property

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

aggregator: Unblock events/queries immediately if the pad is flushing

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

aggregator: Drop serialized events/queries if the pad is flushing

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

aggregator: Block serialized events/queries until the pad has consumed all buffers

Otherwise the caps of the pad might change while the subclass still works with
a buffer of the old caps, assuming the the current pad caps apply to that
buffer. Which then leads to crashes and other nice effects.

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

aggregator: Fix typo in debug output

aggregator: add _get_latency() for subclass usage

API: gst_aggregator_get_latency

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

audiomixer: critical error for blocksize, timeout min/max values

Audiomixer blocksize, cant be 0, hence adjusting the minimum value to 1
timeout value of aggregator is defined with MAX of MAXINT64,
but it cannot cross G_MAXLONG * GST_SECOND - 1
Hence changed the max value of the same

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

tests/aggregator: add timeout handling test for the timeout parameter

aggregator: add latency query handling

aggregator: add a timeout property determining buffer wait time

Determines the amount of time that a pad will wait for a buffer before
being marked unresponsive.

Network sources may fail to produce buffers for an extended period of time,
currently causing the pipeline to stall possibly indefinitely, waiting for
these buffers to appear.

Subclasses should render unresponsive pads with either silence (audio), the
last (video) frame or what makes the most sense in the given context.

aggregator: Replace GMainContext with GAsyncQueue (v2)

The previous implementation kept accumulating GSources,
slowing down the iteration and leaking memory.

Instead of trying to fix the main context flushing, replace
it with a GAsyncQueue which is simple to flush and has
less overhead.

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

aggregator: Set seqnum only when segments are received.

aggregator: Add a streaming lock so to secure flush start action

Without a lock that is taken in FLUSH_START we had a rare race where we
end up aggregating a buffer that was before the whole FLUSH_START/STOP
dance. That could lead to very wrong behaviour in subclasses.

aggregator: Query seeking when a seek failed to see if it was expected

And do not worry if seeking failed on a stream that is not seekable