Src

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 Format with the set_format method. The currently set format determines the format of the internal Segment and any SEGMENT events. The default format for Src is BYTES.

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

* The format is set to BYTES (default). * GstBaseSrcClass::is_seekable returns true.

If all the conditions are met for operating in pull mode, Src 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 BYTES:

* GstBaseSrcClass::is_seekable returns true. * GstBaseSrcClass::query can convert all supported seek formats to the internal format as set with set_format. * 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 PushSrc 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.

Src 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 set_live 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 NO_PREROLL.

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 wait_playing when the GstBaseSrcClass::create function was interrupted by a state change to PAUSED.

The GstBaseSrcClass::get_timess method can be used to implement pseudo-live sources. It only makes sense to implement the GstBaseSrcClass::get_timess function if the source is a live source. The GstBaseSrcClass::get_timess 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 Src for exactly one source pad, which should be named "src". A source implementation (subclass of Src) 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>");
}

typeof (unichar2) typeof (unichar2) 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 SEGMENT_DONE on the bus). This can typically be done with the send_event 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.