[ GIR ( name = "Aggregator" ) ]
[ Version ( since = "1.14" ) ]
public abstract class Aggregator : Element
Manages a set of pads with the purpose of aggregating their buffers.
Control is given to the subclass when all pads have data.
* Base class for mixers and muxers. Subclasses should at least implement the aggregate virtual method.
* Installs a PadChainFunction, a PadEventFullFunction and a PadQueryFunction to queue all serialized data packets per sink pad. Subclasses should not overwrite those, but instead implement sink_event and sink_query as needed.
* When data is queued on all pads, the aggregate vmethod is called.
* One can peek at the data on any given GstAggregatorPad with the
peek_buffer method, and remove it from the pad with the
pop_buffer method. When a buffer has been taken with
pop_buffer, a new buffer can be queued on that pad.
- pop_buffer is called, in which case the caller is guaranteed that the buffer they receive is the same as the peeked buffer. - drop_buffer is called, in which case the caller is guaranteed that the dropped buffer is the one that was peeked. - the subclass implementation of aggregate returns.
Subclasses are only allowed to call these methods from the aggregate thread.
* If the subclass wishes to push a buffer downstream in its aggregate implementation, it should do so through the finish_buffer method. This method will take care of sending and ordering mandatory events such as stream start, caps and segment. Buffer lists can also be pushed out with finish_buffer_list.
* Same goes for EOS events, which should not be pushed directly by the subclass, it should instead return GST_FLOW_EOS in its aggregate implementation.
* Note that the aggregator logic regarding gap event handling is to turn these into gap buffers with matching PTS and duration. It will also flag these buffers with GST_BUFFER_FLAG_GAP and GST_BUFFER_FLAG_DROPPABLE to ease their identification and subsequent processing.
This class used to live in gst-plugins-bad and was moved to core.