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::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:
staticvoid
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>");
}
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.
This is a generic base class for source elements. The following types of sources are supported:
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:
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:
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:
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.