Flags to be used in a #GstBaseParseFrame.

The #GstElement flags that a basesrc element may have.

This class is for elements that receive buffers in an undesired size. While for example raw video contains one image per buffer, the same is not true for a lot of other formats, especially those that come directly from a file. So if you have undefined buffer sizes and require a specific size, this object is for you.

An adapter is created with [gstbase.adapter.Adapter.new_]. It can be freed again with [gobject.object.ObjectWrap.unref].

The theory of operation is like this: All buffers received are put into the adapter using [gstbase.adapter.Adapter.push] and the data is then read back in chunks of the desired size using [gstbase.adapter.Adapter.map]/[gstbase.adapter.Adapter.unmap] and/or [gstbase.adapter.Adapter.copy]. After the data has been processed, it is freed using [gstbase.adapter.Adapter.unmap].

Other methods such as [gstbase.adapter.Adapter.take] and [gstbase.adapter.Adapter.takeBuffer] combine [gstbase.adapter.Adapter.map] and [gstbase.adapter.Adapter.unmap] in one method and are potentially more convenient for some use cases.

For example, a sink pad's chain function that needs to pass data to a library in 512-byte chunks could be implemented like this:

static GstFlowReturn
sink_pad_chain (GstPad *pad, GstObject *parent, GstBuffer *buffer)
{
 MyElement *this;
 GstAdapter *adapter;
 GstFlowReturn ret = GST_FLOW_OK;

 this = MY_ELEMENT (parent);

 adapter = this->adapter;

 // put buffer into adapter
 gst_adapter_push (adapter, buffer);

 // while we can read out 512 bytes, process them
 while (gst_adapter_available (adapter) >= 512 && ret == GST_FLOW_OK) {
   const guint8 *data = gst_adapter_map (adapter, 512);
   // use flowreturn as an error value
   ret = my_library_foo (data);
   gst_adapter_unmap (adapter);
   gst_adapter_flush (adapter, 512);
 }
 return ret;
}

For another example, a simple element inside GStreamer that uses #GstAdapter is the libvisual element.

An element using #GstAdapter in its sink pad chain function should ensure that when the FLUSH_STOP event is received, that any queued data is cleared using [gstbase.adapter.Adapter.clear]. Data should also be cleared or processed on EOS and when changing state from [gst.types.State.Paused] to [gst.types.State.Ready].

Also check the GST_BUFFER_FLAG_DISCONT flag on the buffer. Some elements might need to clear the adapter after a discontinuity.

The adapter will keep track of the timestamps of the buffers that were pushed. The last seen timestamp before the current position can be queried with [gstbase.adapter.Adapter.prevPts]. This function can optionally return the number of bytes between the start of the buffer that carried the timestamp and the current adapter position. The distance is useful when dealing with, for example, raw audio samples because it allows you to calculate the timestamp of the current adapter position by using the last seen timestamp and the amount of bytes since. Additionally, the [gstbase.adapter.Adapter.prevPtsAtOffset] can be used to determine the last seen timestamp at a particular offset in the adapter.

The adapter will also keep track of the offset of the buffers (#GST_BUFFER_OFFSET) that were pushed. The last seen offset before the current position can be queried with [gstbase.adapter.Adapter.prevOffset]. This function can optionally return the number of bytes between the start of the buffer that carried the offset and the current adapter position.

Additionally the adapter also keeps track of the PTS, DTS and buffer offset at the last discontinuity, which can be retrieved with [gstbase.adapter.Adapter.ptsAtDiscont], [gstbase.adapter.Adapter.dtsAtDiscont] and [gstbase.adapter.Adapter.offsetAtDiscont]. The number of bytes that were consumed since then can be queried with [gstbase.adapter.Adapter.distanceFromDiscont].

A last thing to note is that while #GstAdapter is pretty optimized, merging buffers still might be an operation that requires a malloc() and memcpy() operation, and these operations are not the fastest. Because of this, some functions like [gstbase.adapter.Adapter.availableFast] are provided to help speed up such cases should you want to. To avoid repeated memory allocations, [gstbase.adapter.Adapter.copy] can be used to copy data into a (statically allocated) user provided buffer.

#GstAdapter is not MT safe. All operations on an adapter must be serialized by the caller. This is not normally a problem, however, as the normal use case of #GstAdapter is inside one pad's chain function, in which case access is serialized via the pad's STREAM_LOCK.

Note that [gstbase.adapter.Adapter.push] takes ownership of the buffer passed. Use gst_buffer_ref() before pushing it into the adapter if you still want to access the buffer later. The adapter will never modify the data in the buffer pushed in it.

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 #GstAggregatorClass::aggregate virtual method.

• Installs a #GstPadChainFunction, a #GstPadEventFullFunction and a

#GstPadQueryFunction to queue all serialized data packets per sink pad. Subclasses should not overwrite those, but instead implement #GstAggregatorClass::sink_event and #GstAggregatorClass::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

[gstbase.aggregator_pad.AggregatorPad.peekBuffer] method, and remove it from the pad with the gst_aggregator_pad_pop_buffer () method. When a buffer has been taken with pop_buffer (), a new buffer can be queued on that pad.

• When [gstbase.aggregator_pad.AggregatorPad.peekBuffer] or [gstbase.aggregator_pad.AggregatorPad.hasBuffer]

are called, a reference is taken to the returned buffer, which stays valid until either:

• [gstbase.aggregator_pad.AggregatorPad.popBuffer] is called, in which case the caller

is guaranteed that the buffer they receive is the same as the peeked buffer.

• [gstbase.aggregator_pad.AggregatorPad.dropBuffer] is called, in which case the caller

is guaranteed that the dropped buffer is the one that was peeked.

• the subclass implementation of #GstAggregatorClass.aggregate returns.

Subsequent calls to [gstbase.aggregator_pad.AggregatorPad.peekBuffer] or [gstbase.aggregator_pad.AggregatorPad.hasBuffer] return / check the same buffer that was returned / checked, until one of the conditions listed above is met.

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 [gstbase.aggregator.Aggregator.finishBuffer] 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 [gstbase.aggregator.Aggregator.finishBufferList].

• 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. In addition, if the gap event was flagged with GST_GAP_FLAG_MISSING_DATA, a custom meta is added to the resulting gap buffer (GstAggregatorMissingDataMeta).

• Subclasses must use (a subclass of) #GstAggregatorPad for both their

sink and source pads. See [gst.element_class.ElementClass.addStaticPadTemplateWithGtype].

This class used to live in gst-plugins-bad and was moved to core.

The aggregator base class will handle in a thread-safe way all manners of concurrent flushes, seeks, pad additions and removals, leaving to the subclass the responsibility of clipping buffers, and aggregating buffers in the way the implementor sees fit.

It will also take care of event ordering (stream-start, segment, eos).

Basically, a simple implementation will override @aggregate, and call _finish_buffer from inside that function.

Pads managed by a #GstAggregator subclass.

This class used to live in gst-plugins-bad and was moved to core.

This base class is for parser elements that process data and splits it into separate audio/video/whatever frames.

It provides for:

• provides one sink pad and one source pad
• handles state changes
• can operate in pull mode or push mode
• handles seeking in both modes
• handles events (SEGMENT/EOS/FLUSH)
• handles queries (POSITION/DURATION/SEEKING/FORMAT/CONVERT)
• handles flushing

The purpose of this base class is to provide the basic functionality of a parser and share a lot of rather complex code.

Description of the parsing mechanism:

Set-up phase

• #GstBaseParse calls #GstBaseParseClass::start to inform subclass

that data processing is about to start now.

• #GstBaseParse class calls #GstBaseParseClass::set_sink_caps to

inform the subclass about incoming sinkpad caps. Subclass could already set the srcpad caps accordingly, but this might be delayed until calling [gstbase.base_parse.BaseParse.finishFrame] with a non-queued frame.

• At least at this point subclass needs to tell the #GstBaseParse class

how big data chunks it wants to receive (minimum frame size ). It can do this with [gstbase.base_parse.BaseParse.setMinFrameSize].

• #GstBaseParse class sets up appropriate data passing mode (pull/push)

and starts to process the data.

Parsing phase

• #GstBaseParse gathers at least min_frame_size bytes of data either

by pulling it from upstream or collecting buffers in an internal #GstAdapter.

• A buffer of (at least) min_frame_size bytes is passed to subclass

with #GstBaseParseClass::handle_frame. Subclass checks the contents and can optionally return #GST_FLOW_OK along with an amount of data to be skipped to find a valid frame (which will result in a subsequent DISCONT). If, otherwise, the buffer does not hold a complete frame, #GstBaseParseClass::handle_frame can merely return and will be called again when additional data is available. In push mode this amounts to an additional input buffer (thus minimal additional latency), in pull mode this amounts to some arbitrary reasonable buffer size increase.

Of course, [gstbase.base_parse.BaseParse.setMinFrameSize] could also be used if a very specific known amount of additional data is required. If, however, the buffer holds a complete valid frame, it can pass the size of this frame to [gstbase.base_parse.BaseParse.finishFrame].

If acting as a converter, it can also merely indicate consumed input data while simultaneously providing custom output data. Note that baseclass performs some processing (such as tracking overall consumed data rate versus duration) for each finished frame, but other state is only updated upon each call to #GstBaseParseClass::handle_frame (such as tracking upstream input timestamp).

Subclass is also responsible for setting the buffer metadata (e.g. buffer timestamp and duration, or keyframe if applicable). (although the latter can also be done by #GstBaseParse if it is appropriately configured, see below). Frame is provided with timestamp derived from upstream (as much as generally possible), duration obtained from configuration (see below), and offset if meaningful (in pull mode).

Note that #GstBaseParseClass::handle_frame might receive any small amount of input data when leftover data is being drained (e.g. at EOS).

• As part of finish frame processing, just prior to actually pushing

the buffer in question, it is passed to #GstBaseParseClass::pre_push_frame which gives subclass yet one last chance to examine buffer metadata, or to send some custom (tag) events, or to perform custom (segment) filtering.

• During the parsing process #GstBaseParseClass will handle both srcpad

and sinkpad events. They will be passed to subclass if #GstBaseParseClass::sink_event or #GstBaseParseClass::src_event implementations have been provided.

Shutdown phase

• #GstBaseParse class calls #GstBaseParseClass::stop to inform the

subclass that data parsing will be stopped.

Subclass is responsible for providing pad template caps for source and sink pads. The pads need to be named "sink" and "src". It also needs to set the fixed caps on srcpad, when the format is ensured (e.g. when base class calls subclass' #GstBaseParseClass::set_sink_caps function).

This base class uses [gst.types.Format.Default] as a meaning of frames. So, subclass conversion routine needs to know that conversion from [gst.types.Format.Time] to [gst.types.Format.Default] must return the frame number that can be found from the given byte position.

#GstBaseParse uses subclasses conversion methods also for seeking (or otherwise uses its own default one, see also below).

Subclass @start and @stop functions will be called to inform the beginning and end of data processing.

Things that subclass need to take care of:

• Provide pad templates
• Fixate the source pad caps when appropriate
• Inform base class how big data chunks should be retrieved. This is

done with [gstbase.base_parse.BaseParse.setMinFrameSize] function.

• Examine data chunks passed to subclass with

#GstBaseParseClass::handle_frame and pass proper frame(s) to [gstbase.base_parse.BaseParse.finishFrame], and setting src pad caps and timestamps on frame.

• Provide conversion functions
• Update the duration information with [gstbase.base_parse.BaseParse.setDuration]
• Optionally passthrough using [gstbase.base_parse.BaseParse.setPassthrough]
• Configure various baseparse parameters using

[gstbase.base_parse.BaseParse.setAverageBitrate], [gstbase.base_parse.BaseParse.setSyncable] and [gstbase.base_parse.BaseParse.setFrameRate].

• In particular, if subclass is unable to determine a duration, but

parsing (or specs) yields a frames per seconds rate, then this can be provided to #GstBaseParse to enable it to cater for buffer time metadata (which will be taken from upstream as much as possible). Internally keeping track of frame durations and respective sizes that have been pushed provides #GstBaseParse with an estimated bitrate. A default #GstBaseParseClass::convert (used if not overridden) will then use these rates to perform obvious conversions. These rates are also used to update (estimated) duration at regular frame intervals.

Subclasses can override any of the available virtual methods or not, as needed. At minimum @handle_frame needs to be overridden.

Frame (context) data passed to each frame parsing virtual methods. In addition to providing the data to be checked for a valid frame or an already identified frame, it conveys additional metadata or control information from and to the subclass w.r.t. the particular frame in question (rather than global parameters). Some of these may apply to each parsing stage, others only to some a particular one. These parameters are effectively zeroed at start of each frame's processing, i.e. parsing virtual method invocation sequence.

#GstBaseSink is the base class for sink elements in GStreamer, such as xvimagesink or filesink. It is a layer on top of #GstElement that provides a simplified interface to plugin writers. #GstBaseSink handles many details for you, for example: preroll, clock synchronization, state changes, activation in push or pull mode, and queries.

In most cases, when writing sink elements, there is no need to implement class methods from #GstElement or to set functions on pads, because the #GstBaseSink infrastructure should be sufficient.

#GstBaseSink provides support for exactly one sink pad, which should be named "sink". A sink implementation (subclass of #GstBaseSink) should install a pad template in its class_init function, like so:

static void
my_element_class_init (GstMyElementClass *klass)
{
 GstElementClass *gstelement_class = GST_ELEMENT_CLASS (klass);

 // sinktemplate should be a #GstStaticPadTemplate with direction
 // %GST_PAD_SINK and name "sink"
 gst_element_class_add_static_pad_template (gstelement_class, &sinktemplate);

 gst_element_class_set_static_metadata (gstelement_class,
     "Sink name",
     "Sink",
     "My Sink element",
     "The author <my.sink@my.email>");
}

#GstBaseSink will handle the prerolling correctly. This means that it will return [gst.types.StateChangeReturn.Async] from a state change to PAUSED until the first buffer arrives in this element. The base class will call the #GstBaseSinkClass::preroll vmethod with this preroll buffer and will then commit the state change to the next asynchronously pending state.

When the element is set to PLAYING, #GstBaseSink will synchronise on the clock using the times returned from #GstBaseSinkClass::get_times. If this function returns [gst.types.CLOCK_TIME_NONE] for the start time, no synchronisation will be done. Synchronisation can be disabled entirely by setting the object #GstBaseSink:sync property to false.

After synchronisation the virtual method #GstBaseSinkClass::render will be called. Subclasses should minimally implement this method.

Subclasses that synchronise on the clock in the #GstBaseSinkClass::render method are supported as well. These classes typically receive a buffer in the render method and can then potentially block on the clock while rendering. A typical example is an audiosink. These subclasses can use [gstbase.base_sink.BaseSink.waitPreroll] to perform the blocking wait.

Upon receiving the EOS event in the PLAYING state, #GstBaseSink will wait for the clock to reach the time indicated by the stop time of the last #GstBaseSinkClass::get_times call before posting an EOS message. When the element receives EOS in PAUSED, preroll completes, the event is queued and an EOS message is posted when going to PLAYING.

#GstBaseSink will internally use the [gst.types.EventType.Segment] events to schedule synchronisation and clipping of buffers. Buffers that fall completely outside of the current segment are dropped. Buffers that fall partially in the segment are rendered (and prerolled). Subclasses should do any subbuffer clipping themselves when needed.

#GstBaseSink will by default report the current playback position in [gst.types.Format.Time] based on the current clock time and segment information. If no clock has been set on the element, the query will be forwarded upstream.

The #GstBaseSinkClass::set_caps function will be called when the subclass should configure itself to process a specific media type.

The #GstBaseSinkClass::start and #GstBaseSinkClass::stop virtual methods will be called when resources should be allocated. Any #GstBaseSinkClass::preroll, #GstBaseSinkClass::render and #GstBaseSinkClass::set_caps function will be called between the #GstBaseSinkClass::start and #GstBaseSinkClass::stop calls.

The #GstBaseSinkClass::event virtual method will be called when an event is received by #GstBaseSink. Normally this method should only be overridden by very specific elements (such as file sinks) which need to handle the newsegment event specially.

The #GstBaseSinkClass::unlock method is called when the elements should unblock any blocking operations they perform in the #GstBaseSinkClass::render method. This is mostly useful when the #GstBaseSinkClass::render method performs a blocking write on a file descriptor, for example.

The #GstBaseSink:max-lateness property affects how the sink deals with buffers that arrive too late in the sink. A buffer arrives too late in the sink when the presentation time (as a combination of the last segment, buffer timestamp and element base_time) plus the duration is before the current time of the clock. If the frame is later than max-lateness, the sink will drop the buffer without calling the render method. This feature is disabled if sync is disabled, the #GstBaseSinkClass::get_times method does not return a valid start time or max-lateness is set to -1 (the default). Subclasses can use [gstbase.base_sink.BaseSink.setMaxLateness] to configure the max-lateness value.

The #GstBaseSink:qos property will enable the quality-of-service features of the basesink which gather statistics about the real-time performance of the clock synchronisation. For each buffer received in the sink, statistics are gathered and a QOS event is sent upstream with these numbers. This information can then be used by upstream elements to reduce their processing rate, for example.

The #GstBaseSink:async property can be used to instruct the sink to never perform an ASYNC state change. This feature is mostly usable when dealing with non-synchronized streams or sparse streams.

Subclasses can override any of the available virtual methods or not, as needed. At the minimum, the @render method should be overridden to output/present buffers.

This is a generic base class for source elements. The following types of sources are supported:

• random access sources like files
• seekable sources
• live sources

The source can be configured to operate in any #GstFormat with the [gstbase.base_src.BaseSrc.setFormat] method. The currently set format determines the format of the internal #GstSegment and any [gst.types.EventType.Segment] events. The default format for #GstBaseSrc is [gst.types.Format.Bytes].

#GstBaseSrc always supports push mode scheduling. If the following conditions are met, it also supports pull mode scheduling:

• The format is set to [gst.types.Format.Bytes] (default).
• #GstBaseSrcClass::is_seekable returns true.

If all the conditions are met for operating in pull mode, #GstBaseSrc is automatically seekable in push mode as well. The following conditions must be met to make the element seekable in push mode when the format is not [gst.types.Format.Bytes]:

• #GstBaseSrcClass::is_seekable returns true.
• #GstBaseSrcClass::query can convert all supported seek formats to the

internal format as set with [gstbase.base_src.BaseSrc.setFormat].

• #GstBaseSrcClass::do_seek is implemented, performs the seek and returns

true.

When the element does not meet the requirements to operate in pull mode, the offset and length in the #GstBaseSrcClass::create method should be ignored. It is recommended to subclass #GstPushSrc instead, in this situation. If the element can operate in pull mode but only with specific offsets and lengths, it is allowed to generate an error when the wrong values are passed to the #GstBaseSrcClass::create function.

#GstBaseSrc has support for live sources. Live sources are sources that when paused discard data, such as audio or video capture devices. A typical live source also produces data at a fixed rate and thus provides a clock to publish this rate. Use [gstbase.base_src.BaseSrc.setLive] to activate the live source mode.

A live source does not produce data in the PAUSED state. This means that the #GstBaseSrcClass::create method will not be called in PAUSED but only in PLAYING. To signal the pipeline that the element will not produce data, the return value from the READY to PAUSED state will be [gst.types.StateChangeReturn.NoPreroll].

A typical live source will timestamp the buffers it creates with the current running time of the pipeline. This is one reason why a live source can only produce data in the PLAYING state, when the clock is actually distributed and running.

Live sources that synchronize and block on the clock (an audio source, for example) can use [gstbase.base_src.BaseSrc.waitPlaying] when the #GstBaseSrcClass::create function was interrupted by a state change to PAUSED.

The #GstBaseSrcClass::get_times method can be used to implement pseudo-live sources. It only makes sense to implement the #GstBaseSrcClass::get_times function if the source is a live source. The #GstBaseSrcClass::get_times function should return timestamps starting from 0, as if it were a non-live source. The base class will make sure that the timestamps are transformed into the current running_time. The base source will then wait for the calculated running_time before pushing out the buffer.

For live sources, the base class will by default report a latency of 0. For pseudo live sources, the base class will by default measure the difference between the first buffer timestamp and the start time of get_times and will report this value as the latency. Subclasses should override the query function when this behaviour is not acceptable.

There is only support in #GstBaseSrc for exactly one source pad, which should be named "src". A source implementation (subclass of #GstBaseSrc) should install a pad template in its class_init function, like so:

static void
my_element_class_init (GstMyElementClass *klass)
{
 GstElementClass *gstelement_class = GST_ELEMENT_CLASS (klass);
 // srctemplate should be a #GstStaticPadTemplate with direction
 // %GST_PAD_SRC and name "src"
 gst_element_class_add_static_pad_template (gstelement_class, &srctemplate);

 gst_element_class_set_static_metadata (gstelement_class,
    "Source name",
    "Source",
    "My Source element",
    "The author <my.sink@my.email>");
}

Controlled shutdown of live sources in applications

Applications that record from a live source may want to stop recording in a controlled way, so that the recording is stopped, but the data already in the pipeline is processed to the end (remember that many live sources would go on recording forever otherwise). For that to happen the application needs to make the source stop recording and send an EOS event down the pipeline. The application would then wait for an EOS message posted on the pipeline's bus to know when all data has been processed and the pipeline can safely be stopped.

An application may send an EOS event to a source element to make it perform the EOS logic (send EOS event downstream or post a [gst.types.MessageType.SegmentDone] on the bus). This can typically be done with the [gst.element.Element.sendEvent] function on the element or its parent bin.

After the EOS has been sent to the element, the application should wait for an EOS message to be posted on the pipeline's bus. Once this EOS message is received, it may safely shut down the entire pipeline.

Subclasses can override any of the available virtual methods or not, as needed. At the minimum, the @create method should be overridden to produce buffers.

This base class is for filter elements that process data. Elements that are suitable for implementation using #GstBaseTransform are ones where the size and caps of the output is known entirely from the input caps and buffer sizes. These include elements that directly transform one buffer into another, modify the contents of a buffer in-place, as well as elements that collate multiple input buffers into one output buffer, or that expand one input buffer into multiple output buffers. See below for more concrete use cases.

It provides for:

• one sinkpad and one srcpad
• Possible formats on sink and source pad implemented

with custom transform_caps function. By default uses same format on sink and source.

• Handles state changes
• Does flushing
• Push mode
• Pull mode if the sub-class transform can operate on arbitrary data

Use Cases

Passthrough mode

• Element has no interest in modifying the buffer. It may want to inspect it,

in which case the element should have a transform_ip function. If there is no transform_ip function in passthrough mode, the buffer is pushed intact.

• The #GstBaseTransformClass.passthrough_on_same_caps variable

will automatically set/unset passthrough based on whether the element negotiates the same caps on both pads.

• #GstBaseTransformClass.passthrough_on_same_caps on an element that

doesn't implement a transform_caps function is useful for elements that only inspect data (such as level)

• Example elements

• Level
• Videoscale, audioconvert, videoconvert, audioresample in certain modes.

Modifications in-place - input buffer and output buffer are the same thing.

• The element must implement a transform_ip function.
• Output buffer size must <= input buffer size
• If the always_in_place flag is set, non-writable buffers will be copied

and passed to the transform_ip function, otherwise a new buffer will be created and the transform function called.

• Incoming writable buffers will be passed to the transform_ip function

immediately.

• only implementing transform_ip and not transform implies always_in_place = true

• Example elements:
• Volume
• Audioconvert in certain modes (signed/unsigned conversion)
• videoconvert in certain modes (endianness swapping)

Modifications only to the caps/metadata of a buffer

• The element does not require writable data, but non-writable buffers

should be subbuffered so that the meta-information can be replaced.

• Elements wishing to operate in this mode should replace the

prepare_output_buffer method to create subbuffers of the input buffer and set always_in_place to true

• Example elements
• Capsfilter when setting caps on outgoing buffers that have

none.

• identity when it is going to re-timestamp buffers by

datarate.

Normal mode

• always_in_place flag is not set, or there is no transform_ip function
• Element will receive an input buffer and output buffer to operate on.
• Output buffer is allocated by calling the prepare_output_buffer function.
• Example elements:
• Videoscale, videoconvert, audioconvert when doing

scaling/conversions

Special output buffer allocations

• Elements which need to do special allocation of their output buffers

beyond allocating output buffers via the negotiated allocator or buffer pool should implement the prepare_output_buffer method.

• Example elements:
• efence

Sub-class settable flags on GstBaseTransform

• passthrough

• Implies that in the current configuration, the sub-class is not interested in modifying the buffers.
• Elements which are always in passthrough mode whenever the same caps has been negotiated on both pads can set the class variable passthrough_on_same_caps to have this behaviour automatically.

• always_in_place
• Determines whether a non-writable buffer will be copied before passing

to the transform_ip function.

• Implied true if no transform function is implemented.
• Implied false if ONLY transform function is implemented.

Subclasses can override any of the available virtual methods or not, as needed. At minimum either @transform or @transform_ip need to be overridden. If the element can overwrite the input data with the results (data is of the same type and quantity) it should provide @transform_ip.

#GstBitReader provides a bit reader that can read any number of bits from a memory buffer. It provides functions for reading any number of bits into 8, 16, 32 and 64 bit variables.

#GstBitWriter provides a bit writer that can write any number of bits into a memory buffer. It provides functions for writing any number of bits into 8, 16, 32 and 64 bit variables.

#GstByteReader provides a byte reader that can read different integer and floating point types from a memory buffer. It provides functions for reading signed/unsigned, little/big endian integers of 8, 16, 24, 32 and 64 bits and functions for reading little/big endian floating points numbers of 32 and 64 bits. It also provides functions to read NUL-terminated strings in various character encodings.

#GstByteWriter provides a byte writer and reader that can write/read different integer and floating point types to/from a memory buffer. It provides functions for writing/reading signed/unsigned, little/big endian integers of 8, 16, 24, 32 and 64 bits and functions for reading little/big endian floating points numbers of 32 and 64 bits. It also provides functions to write/read NUL-terminated strings in various character encodings.

Structure used by the collect_pads.

Manages a set of pads that operate in collect mode. This means that control is given to the manager of this object when all pads have data.

• Collectpads are created with [gstbase.collect_pads.CollectPads.new_]. A callback should then

be installed with gst_collect_pads_set_function ().

• Pads are added to the collection with [gstbase.collect_pads.CollectPads.addPad]/

[gstbase.collect_pads.CollectPads.removePad]. The pad has to be a sinkpad. When added, the chain, event and query functions of the pad are overridden. The element_private of the pad is used to store private information for the collectpads.

• For each pad, data is queued in the _chain function or by

performing a pull_range.

• When data is queued on all pads in waiting mode, the callback function is called.

• Data can be dequeued from the pad with the [gstbase.collect_pads.CollectPads.pop] method.

One can peek at the data with the [gstbase.collect_pads.CollectPads.peek] function. These functions will return null if the pad received an EOS event. When all pads return null from a [gstbase.collect_pads.CollectPads.peek], the element can emit an EOS event itself.

• Data can also be dequeued in byte units using the [gstbase.collect_pads.CollectPads.available],

[gstbase.collect_pads.CollectPads.readBuffer] and [gstbase.collect_pads.CollectPads.flush] calls.

• Elements should call [gstbase.collect_pads.CollectPads.start] and [gstbase.collect_pads.CollectPads.stop] in

their state change functions to start and stop the processing of the collectpads. The [gstbase.collect_pads.CollectPads.stop] call should be called before calling the parent element state change function in the PAUSED_TO_READY state change to ensure no pad is blocked and the element can finish streaming.

• [gstbase.collect_pads.CollectPads.setWaiting] sets a pad to waiting or non-waiting mode.

CollectPads element is not waiting for data to be collected on non-waiting pads. Thus these pads may but need not have data when the callback is called. All pads are in waiting mode by default.

#GstDataQueue is an object that handles threadsafe queueing of objects. It also provides size-related functionality. This object should be used for any #GstElement that wishes to provide some sort of queueing functionality.

Structure used by #GstDataQueue. You can supply a different structure, as long as the top of the structure is identical to this structure.

Structure describing the size of a queue.

Utility struct to help handling #GstFlowReturn combination. Useful for #GstElement<!-- -->s that have multiple source pads and need to combine the different #GstFlowReturn for those pads.

#GstFlowCombiner works by using the last #GstFlowReturn for all #GstPad it has in its list and computes the combined return value and provides it to the caller.

To add a new pad to the #GstFlowCombiner use [gstbase.flow_combiner.FlowCombiner.addPad]. The new #GstPad is stored with a default value of [gst.types.FlowReturn.Ok].

In case you want a #GstPad to be removed, use [gstbase.flow_combiner.FlowCombiner.removePad].

Please be aware that this struct isn't thread safe as its designed to be used by demuxers, those usually will have a single thread operating it.

These functions will take refs on the passed #GstPad<!-- -->s.

Aside from reducing the user's code size, the main advantage of using this helper struct is to follow the standard rules for #GstFlowReturn combination. These rules are:

• [gst.types.FlowReturn.Eos]: only if all returns are EOS too
• [gst.types.FlowReturn.NotLinked]: only if all returns are NOT_LINKED too
• [gst.types.FlowReturn.Error] or below: if at least one returns an error return
• [gst.types.FlowReturn.NotNegotiated]: if at least one returns a not-negotiated return
• [gst.types.FlowReturn.Flushing]: if at least one returns flushing
• [gst.types.FlowReturn.Ok]: otherwise

[gst.types.FlowReturn.Error] or below, GST_FLOW_NOT_NEGOTIATED and GST_FLOW_FLUSHING are returned immediately from the [gstbase.flow_combiner.FlowCombiner.updateFlow] function.

This class is mostly useful for elements that cannot do random access, or at least very slowly. The source usually prefers to push out a fixed size buffer.

Subclasses usually operate in a format that is different from the default GST_FORMAT_BYTES format of #GstBaseSrc.

Classes extending this base class will usually be scheduled in a push based mode. If the peer accepts to operate without offsets and within the limits of the allowed block size, this class can operate in getrange based mode automatically. To make this possible, the subclass should implement and override the SCHEDULING query.

The subclass should extend the methods from the baseclass in addition to the ::create method.

Seeking, flushing, scheduling and sync is all handled by this base class.

Subclasses can override any of the available virtual methods or not, as needed. At the minimum, the @fill method should be overridden to produce buffers.

#GstQueueArray is an object that provides standard queue functionality based on an array instead of linked lists. This reduces the overhead caused by memory management by a large factor.

The opaque #GstTypeFindData structure.