Gst-0.10 Python API Documentation

Class: Gst.Bin

Implements: Gst.ChildProxy

Known subclasses: Gst.Pipeline

Subclass of: Gst.Element

#GstBin is an element that can contain other #GstElement, allowing them to be managed as a group. Pads from the child elements can be ghosted to the bin, see #GstGhostPad. This makes the bin look like any other elements and enables creation of higher-level abstraction elements. A new #GstBin is created with gst_bin_new(). Use a #GstPipeline instead if you want to create a toplevel bin because a normal bin doesn't have a bus or handle clock distribution of its own. After the bin has been created you will typically add elements to it with gst_bin_add(). You can remove elements with gst_bin_remove(). An element can be retrieved from a bin with gst_bin_get_by_name(), using the elements name. gst_bin_get_by_name_recurse_up() is mainly used for internal purposes and will query the parent bins when the element is not found in the current bin. An iterator of elements in a bin can be retrieved with gst_bin_iterate_elements(). Various other iterators exist to retrieve the elements in a bin. gst_object_unref() is used to drop your reference to the bin. The #GstBin::element-added signal is fired whenever a new element is added to the bin. Likewise the #GstBin::element-removed signal is fired whenever an element is removed from the bin. <refsect2><title>Notes</title> <para> A #GstBin internally intercepts every #GstMessage posted by its children and implements the following default behaviour for each of them: <variablelist> <varlistentry> <term>GST_MESSAGE_EOS</term> <listitem><para>This message is only posted by sinks in the PLAYING state. If all sinks posted the EOS message, this bin will post and EOS message upwards.</para></listitem> </varlistentry> <varlistentry> <term>GST_MESSAGE_SEGMENT_START</term> <listitem><para>just collected and never forwarded upwards. The messages are used to decide when all elements have completed playback of their segment.</para></listitem> </varlistentry> <varlistentry> <term>GST_MESSAGE_SEGMENT_DONE</term> <listitem><para> Is posted by #GstBin when all elements that posted a SEGMENT_START have posted a SEGMENT_DONE.</para></listitem> </varlistentry> <varlistentry> <term>GST_MESSAGE_DURATION</term> <listitem><para> Is posted by an element that detected a change in the stream duration. The default bin behaviour is to clear any cached duration values so that the next duration query will perform a full duration recalculation. The duration change is posted to the application so that it can refetch the new duration with a duration query. Note that these messages can be posted before the bin is prerolled, in which case the duration query might fail. </para></listitem> </varlistentry> <varlistentry> <term>GST_MESSAGE_CLOCK_LOST</term> <listitem><para> This message is posted by an element when it can no longer provide a clock. The default bin behaviour is to check if the lost clock was the one provided by the bin. If so and the bin is currently in the PLAYING state, the message is forwarded to the bin parent. This message is also generated when a clock provider is removed from the bin. If this message is received by the application, it should PAUSE the pipeline and set it back to PLAYING to force a new clock distribution. </para></listitem> </varlistentry> <varlistentry> <term>GST_MESSAGE_CLOCK_PROVIDE</term> <listitem><para> This message is generated when an element can provide a clock. This mostly happens when a new clock provider is added to the bin. The default behaviour of the bin is to mark the currently selected clock as dirty, which will perform a clock recalculation the next time the bin is asked to provide a clock. This message is never sent tot the application but is forwarded to the parent of the bin. </para></listitem> </varlistentry> <varlistentry> <term>OTHERS</term> <listitem><para> posted upwards.</para></listitem> </varlistentry> </variablelist> A #GstBin implements the following default behaviour for answering to a #GstQuery: <variablelist> <varlistentry> <term>GST_QUERY_DURATION</term> <listitem><para>If the query has been asked before with the same format and the bin is a toplevel bin (ie. has no parent), use the cached previous value. If no previous value was cached, the query is sent to all sink elements in the bin and the MAXIMUM of all values is returned. If the bin is a toplevel bin the value is cached. If no sinks are available in the bin, the query fails. </para></listitem> </varlistentry> <varlistentry> <term>GST_QUERY_POSITION</term> <listitem><para>The query is sent to all sink elements in the bin and the MAXIMUM of all values is returned. If no sinks are available in the bin, the query fails. </para></listitem> </varlistentry> <varlistentry> <term>OTHERS</term> <listitem><para>the query is forwarded to all sink elements, the result of the first sink that answers the query successfully is returned. If no sink is in the bin, the query fails.</para></listitem> </varlistentry> </variablelist> A #GstBin will by default forward any event sent to it to all sink elements. If all the sinks return TRUE, the bin will also return TRUE, else FALSE is returned. If no sinks are in the bin, the event handler will return TRUE. </para> </refsect2> Last reviewed on 2006-04-28 (0.10.6)

Properties

bool"async-handling"read/write

If set to #TRUE, the bin will handle asynchronous state changes. This should be used only if the bin subclass is modifying the state of its children on its own.

bool"message-forward"read/write

Forward all children messages, even those that would normally be filtered by the bin. This can be interesting when one wants to be notified of the EOS state of individual elements, for example. The messages are converted to an ELEMENT message with the bin as the source. The structure of the message is named 'GstBinForwarded' and contains a field named 'message' of type GST_TYPE_MESSAGE that contains the original forwarded message.

Signals

bool"do-latency"(self, bin)

Will be emitted when the bin needs to perform latency calculations. This signal is only emited for toplevel bins or when async-handling is enabled. Only one signal handler is invoked. If no signals are connected, the default handler is invoked, which will query and distribute the lowest possible latency to all sinks. Connect to this signal if the default latency calculations are not sufficient, like when you need different latencies for different sinks in the same pipeline.

void"element-removed"(self, bin, element)

Will be emitted after the element was removed from the bin.

void"element-added"(self, bin, element)

Will be emitted after the element was added to the bin.

Methods

booladd(element)

booladd_element(element)

booldo_latency()

voidelement_added(child)

voidelement_removed(child)

Gst.Padfind_unconnected_pad(direction)

Gst.Padfind_unlinked_pad(direction)

Gst.Elementget_by_interface(iface)

Gst.Elementget_by_name(name)

Gst.Elementget_by_name_recurse_up(name)

voidhandle_message(message)

boolrecalculate_latency()

boolremove(element)

boolremove_element(element)

Class: Gst.Buffer

Subclass of: Gst.MiniObject

Buffers are the basic unit of data transfer in GStreamer. The #GstBuffer type provides all the state necessary to define a region of memory as part of a stream. Sub-buffers are also supported, allowing a smaller region of a buffer to become its own buffer, with mechanisms in place to ensure that neither memory space goes away prematurely. Buffers are usually created with gst_buffer_new(). After a buffer has been created one will typically allocate memory for it and set the size of the buffer data. The following example creates a buffer that can hold a given video frame with a given width, height and bits per plane. <example> <title>Creating a buffer for a video frame</title> <programlisting> GstBuffer *buffer; gint size, width, height, bpp; ... size = width * height * bpp; buffer = gst_buffer_new (); GST_BUFFER_SIZE (buffer) = size; GST_BUFFER_MALLOCDATA (buffer) = g_malloc (size); GST_BUFFER_DATA (buffer) = GST_BUFFER_MALLOCDATA (buffer); ... </programlisting> </example> Alternatively, use gst_buffer_new_and_alloc() to create a buffer with preallocated data of a given size. The data pointed to by the buffer can be retrieved with the GST_BUFFER_DATA() macro. The size of the data can be found with GST_BUFFER_SIZE(). For buffers of size 0, the data pointer is undefined (usually NULL) and should never be used. If an element knows what pad you will push the buffer out on, it should use gst_pad_alloc_buffer() instead to create a buffer. This allows downstream elements to provide special buffers to write in, like hardware buffers. A buffer has a pointer to a #GstCaps describing the media type of the data in the buffer. Attach caps to the buffer with gst_buffer_set_caps(); this is typically done before pushing out a buffer using gst_pad_push() so that the downstream element knows the type of the buffer. A buffer will usually have a timestamp, and a duration, but neither of these are guaranteed (they may be set to #GST_CLOCK_TIME_NONE). Whenever a meaningful value can be given for these, they should be set. The timestamp and duration are measured in nanoseconds (they are #GstClockTime values). A buffer can also have one or both of a start and an end offset. These are media-type specific. For video buffers, the start offset will generally be the frame number. For audio buffers, it will be the number of samples produced so far. For compressed data, it could be the byte offset in a source or destination file. Likewise, the end offset will be the offset of the end of the buffer. These can only be meaningfully interpreted if you know the media type of the buffer (the #GstCaps set on it). Either or both can be set to #GST_BUFFER_OFFSET_NONE. gst_buffer_ref() is used to increase the refcount of a buffer. This must be done when you want to keep a handle to the buffer after pushing it to the next element. To efficiently create a smaller buffer out of an existing one, you can use gst_buffer_create_sub(). If a plug-in wants to modify the buffer data in-place, it should first obtain a buffer that is safe to modify by using gst_buffer_make_writable(). This function is optimized so that a copy will only be made when it is necessary. A plugin that only wishes to modify the metadata of a buffer, such as the offset, timestamp or caps, should use gst_buffer_make_metadata_writable(), which will create a subbuffer of the original buffer to ensure the caller has sole ownership, and not copy the buffer data. Several flags of the buffer can be set and unset with the GST_BUFFER_FLAG_SET() and GST_BUFFER_FLAG_UNSET() macros. Use GST_BUFFER_FLAG_IS_SET() to test if a certain #GstBufferFlag is set. Buffers can be efficiently merged into a larger buffer with gst_buffer_merge() and gst_buffer_span() if the gst_buffer_is_span_fast() function returns TRUE. An element should either unref the buffer or push it out on a src pad using gst_pad_push() (see #GstPad). Buffers are usually freed by unreffing them with gst_buffer_unref(). When the refcount drops to 0, any data pointed to by GST_BUFFER_MALLOCDATA() will also be freed. Last reviewed on August 11th, 2006 (0.10.10)

Methods

voidcopy_metadata(src, flags)

Gst.Buffercreate_sub(offset, size)

Gst.Capsget_caps()

boolis_metadata_writable()

boolis_span_fast(buf2)

Gst.Buffermake_metadata_writable()

voidset_caps(caps)

Gst.Bufferspan(offset, buf2, len)

voidstamp(src)

Class: Gst.BufferList

Subclass of: Gst.MiniObject

Buffer lists are units of grouped scatter/gather data transfer in GStreamer. Buffer lists are created with gst_buffer_list_new() and filled with data using a #GstBufferListIterator. The iterator has no current buffer; its cursor position lies between buffers, immediately before the buffer that would be returned by gst_buffer_list_iterator_next(). After iterating to the end of a group the iterator must be advanced to the next group by a call to gst_buffer_list_iterator_next_group() before any further calls to gst_buffer_list_iterator_next() can return buffers again. The cursor position of a newly created iterator lies before the first group; a call to gst_buffer_list_iterator_next_group() is necessary before calls to gst_buffer_list_iterator_next() can return buffers. <informalfigure> <programlisting> +--- group0 ----------------------+--- group1 ------------+ | buffer0 buffer1 buffer2 | buffer3 buffer4 | ^ ^ ^ ^ ^ ^ ^ ^ Iterator positions between buffers </programlisting> </informalfigure> The gst_buffer_list_iterator_remove(), gst_buffer_list_iterator_steal(), gst_buffer_list_iterator_take() and gst_buffer_list_iterator_do() functions are not defined in terms of the cursor position; they operate on the last element returned from gst_buffer_list_iterator_next(). The basic use pattern of creating a buffer list with an iterator is as follows: <example> <title>Creating a buffer list</title> <programlisting> GstBufferList *list; GstBufferListIterator *it; list = gst_buffer_list_new (); it = gst_buffer_list_iterate (list); gst_buffer_list_iterator_add_group (it); gst_buffer_list_iterator_add (it, header1); gst_buffer_list_iterator_add (it, data1); gst_buffer_list_iterator_add_group (it); gst_buffer_list_iterator_add (it, header2); gst_buffer_list_iterator_add (it, data2); gst_buffer_list_iterator_add_group (it); gst_buffer_list_iterator_add (it, header3); gst_buffer_list_iterator_add (it, data3); ... gst_buffer_list_iterator_free (it); </programlisting> </example> The basic use pattern of iterating over a buffer list is as follows: <example> <title>Iterating a buffer list</title> <programlisting> GstBufferListIterator *it; it = gst_buffer_list_iterate (list); while (gst_buffer_list_iterator_next_group (it)) { while ((buffer = gst_buffer_list_iterator_next (it)) != NULL) { do_something_with_buffer (buffer); } } gst_buffer_list_iterator_free (it); </programlisting> </example> The basic use pattern of modifying a buffer in a list is as follows: <example> <title>Modifying the data of the first buffer in a list</title> <programlisting> GstBufferListIterator *it; list = gst_buffer_list_make_writable (list); it = gst_buffer_list_iterate (list); if (gst_buffer_list_iterator_next_group (it)) { GstBuffer *buf buf = gst_buffer_list_iterator_next (it); if (buf != NULL) { buf = gst_buffer_list_iterator_do (it, (GstBufferListDoFunction) gst_mini_object_make_writable, NULL); modify_data (GST_BUFFER_DATA (buf)); } } gst_buffer_list_iterator_free (it); </programlisting> </example>

Methods

voidforeach(func, user_data)

Gst.Bufferget(group, idx)

intn_groups()

Class: Gst.Bus

Subclass of: Gst.Object

The #GstBus is an object responsible for delivering #GstMessage packets in a first-in first-out way from the streaming threads (see #GstTask) to the application. Since the application typically only wants to deal with delivery of these messages from one thread, the GstBus will marshall the messages between different threads. This is important since the actual streaming of media is done in another thread than the application. The GstBus provides support for #GSource based notifications. This makes it possible to handle the delivery in the glib mainloop. The #GSource callback function gst_bus_async_signal_func() can be used to convert all bus messages into signal emissions. A message is posted on the bus with the gst_bus_post() method. With the gst_bus_peek() and gst_bus_pop() methods one can look at or retrieve a previously posted message. The bus can be polled with the gst_bus_poll() method. This methods blocks up to the specified timeout value until one of the specified messages types is posted on the bus. The application can then gst_bus_pop() the messages from the bus to handle them. Alternatively the application can register an asynchronous bus function using gst_bus_add_watch_full() or gst_bus_add_watch(). This function will install a #GSource in the default glib main loop and will deliver messages a short while after they have been posted. Note that the main loop should be running for the asynchronous callbacks. It is also possible to get messages from the bus without any thread marshalling with the gst_bus_set_sync_handler() method. This makes it possible to react to a message in the same thread that posted the message on the bus. This should only be used if the application is able to deal with messages from different threads. Every #GstPipeline has one bus. Note that a #GstPipeline will set its bus into flushing state when changing from READY to NULL state. Last reviewed on 2006-03-12 (0.10.5)

Signals

void"message"(self, bus, message)

A message has been posted on the bus. This signal is emitted from a GSource added to the mainloop. this signal will only be emitted when there is a mainloop running.

void"sync-message"(self, bus, message)

A message has been posted on the bus. This signal is emitted from the thread that posted the message so one has to be careful with locking. This signal will not be emitted by default, you have to set up gst_bus_sync_signal_handler() as a sync handler if you want this signal to be emitted when a message is posted on the bus, like this: <programlisting> gst_bus_set_sync_handler (bus, gst_bus_sync_signal_handler, yourdata); </programlisting>

Methods

voidadd_signal_watch()

voidadd_signal_watch_full(priority)

intadd_watch_full(priority, func, user_data, notify)

boolasync_signal_func(message, data)

voiddisable_sync_message_emission()

voidenable_sync_message_emission()

boolhave_pending()

voidmessage(message)

Gst.Messagepeek()

Gst.Messagepoll(events, timeout)

Gst.Messagepop_filtered(types)

boolpost(message)

voidremove_signal_watch()

voidset_flushing(flushing)

voidsync_message(message)

Gst.BusSyncReplysync_signal_handler(message, data)

Gst.Messagetimed_pop(timeout)

Gst.Messagetimed_pop_filtered(timeout, types)

Interface: Gst.ChildProxy

Classes implementing Gst.ChildProxy: Gst.Bin, Gst.Pipeline

This interface abstracts handling of property sets for elements with children. Imagine elements such as mixers or polyphonic generators. They all have multiple #GstPad or some kind of voice objects. Another use case are container elements like #GstBin. The element implementing the interface acts as a parent for those child objects. By implementing this interface the child properties can be accessed from the parent element by using gst_child_proxy_get() and gst_child_proxy_set(). Property names are written as "child-name::property-name". The whole naming scheme is recursive. Thus "child1::child2::property" is valid too, if "child1" and "child2" implement the #GstChildProxy interface.

Signals

none"child-added"(self, child_proxy, object)

none"child-removed"(self, child_proxy, object)

Methods

voidchild_added(child)

voidchild_removed(child)

Gst.Objectget_child_by_index(index)

Gst.Objectget_child_by_name(name)

intget_children_count()

Class: Gst.Clock

Known subclasses: Gst.SystemClock

Subclass of: Gst.Object

GStreamer uses a global clock to synchronize the plugins in a pipeline. Different clock implementations are possible by implementing this abstract base class or, more conveniently, by subclassing #GstSystemClock. The #GstClock returns a monotonically increasing time with the method gst_clock_get_time(). Its accuracy and base time depend on the specific clock implementation but time is always expressed in nanoseconds. Since the baseline of the clock is undefined, the clock time returned is not meaningful in itself, what matters are the deltas between two clock times. The time returned by a clock is called the absolute time. The pipeline uses the clock to calculate the running time. Usually all renderers synchronize to the global clock using the buffer timestamps, the newsegment events and the element's base time, see #GstPipeline. A clock implementation can support periodic and single shot clock notifications both synchronous and asynchronous. One first needs to create a #GstClockID for the periodic or single shot notification using gst_clock_new_single_shot_id() or gst_clock_new_periodic_id(). To perform a blocking wait for the specific time of the #GstClockID use the gst_clock_id_wait(). To receive a callback when the specific time is reached in the clock use gst_clock_id_wait_async(). Both these calls can be interrupted with the gst_clock_id_unschedule() call. If the blocking wait is unscheduled a return value of #GST_CLOCK_UNSCHEDULED is returned. Periodic callbacks scheduled async will be repeatedly called automatically until it is unscheduled. To schedule a sync periodic callback, gst_clock_id_wait() should be called repeatedly. The async callbacks can happen from any thread, either provided by the core or from a streaming thread. The application should be prepared for this. A #GstClockID that has been unscheduled cannot be used again for any wait operation, a new #GstClockID should be created and the old unscheduled one should be destroyed with gst_clock_id_unref(). It is possible to perform a blocking wait on the same #GstClockID from multiple threads. However, registering the same #GstClockID for multiple async notifications is not possible, the callback will only be called for the thread registering the entry last. None of the wait operations unref the #GstClockID, the owner is responsible for unreffing the ids itself. This holds for both periodic and single shot notifications. The reason being that the owner of the #GstClockID has to keep a handle to the #GstClockID to unblock the wait on FLUSHING events or state changes and if the entry would be unreffed automatically, the handle might become invalid without any notification. These clock operations do not operate on the running time, so the callbacks will also occur when not in PLAYING state as if the clock just keeps on running. Some clocks however do not progress when the element that provided the clock is not PLAYING. When a clock has the #GST_CLOCK_FLAG_CAN_SET_MASTER flag set, it can be slaved to another #GstClock with the gst_clock_set_master(). The clock will then automatically be synchronized to this master clock by repeatedly sampling the master clock and the slave clock and recalibrating the slave clock with gst_clock_set_calibration(). This feature is mostly useful for plugins that have an internal clock but must operate with another clock selected by the #GstPipeline. They can track the offset and rate difference of their internal clock relative to the master clock by using the gst_clock_get_calibration() function. The master/slave synchronisation can be tuned with the #GstClock:timeout, #GstClock:window-size and #GstClock:window-threshold properties. The #GstClock:timeout property defines the interval to sample the master clock and run the calibration functions. #GstClock:window-size defines the number of samples to use when calibrating and #GstClock:window-threshold defines the minimum number of samples before the calibration is performed. Last reviewed on 2009-05-21 (0.10.24)

Properties

int"window-threshold"read/write

bool"stats"read/write

int"window-size"read/write

int"timeout"read/write

Methods

bool, floatadd_observation(slave, master)

Gst.ClockTimeadjust_unlocked(internal)

Gst.ClockTimechange_resolution(old_resolution, new_resolution)

void, Gst.ClockTime, Gst.ClockTime, Gst.ClockTime, Gst.ClockTimeget_calibration()

Gst.ClockTimeget_internal_time()

Gst.Clockget_master()

Gst.ClockTimeget_resolution()

Gst.ClockTimeget_time()

intid_compare_func(id1, id2)(static method)

Gst.ClockTimeid_get_time(id)(static method)

Gst.ClockIDid_ref(id)(static method)

voidid_unref(id)(static method)

voidid_unschedule(id)(static method)

Gst.ClockReturn, Gst.ClockTimeDiffid_wait(id)(static method)

Gst.ClockReturnid_wait_async_full(id, func, user_data, destroy_data)(static method)

Gst.ClockIDnew_periodic_id(start_time, interval)

Gst.ClockIDnew_single_shot_id(time)

boolperiodic_id_reinit(id, start_time, interval)

voidset_calibration(internal, external, rate_num, rate_denom)

boolset_master(master)

Gst.ClockTimeset_resolution(resolution)

boolsingle_shot_id_reinit(id, time)

Gst.ClockTimeunadjust_unlocked(external)

voidunschedule(entry)

Gst.ClockReturnwait_async(entry)

Gst.ClockReturnwait_jitter(entry, jitter)

Abstract Class: Gst.Element

Known subclasses: Gst.Bin

Subclass of: Gst.Object

GstElement is the abstract base class needed to construct an element that can be used in a GStreamer pipeline. Please refer to the plugin writers guide for more information on creating #GstElement subclasses. The name of a #GstElement can be get with gst_element_get_name() and set with gst_element_set_name(). For speed, GST_ELEMENT_NAME() can be used in the core when using the appropriate locking. Do not use this in plug-ins or applications in order to retain ABI compatibility. All elements have pads (of the type #GstPad). These pads link to pads on other elements. #GstBuffer flow between these linked pads. A #GstElement has a #GList of #GstPad structures for all their input (or sink) and output (or source) pads. Core and plug-in writers can add and remove pads with gst_element_add_pad() and gst_element_remove_pad(). A pad of an element can be retrieved by name with gst_element_get_pad(). An iterator of all pads can be retrieved with gst_element_iterate_pads(). Elements can be linked through their pads. If the link is straightforward, use the gst_element_link() convenience function to link two elements, or gst_element_link_many() for more elements in a row. Use gst_element_link_filtered() to link two elements constrained by a specified set of #GstCaps. For finer control, use gst_element_link_pads() and gst_element_link_pads_filtered() to specify the pads to link on each element by name. Each element has a state (see #GstState). You can get and set the state of an element with gst_element_get_state() and gst_element_set_state(). Setting a state triggers a #GstStateChange. To get a string representation of a #GstState, use gst_element_state_get_name(). You can get and set a #GstClock on an element using gst_element_get_clock() and gst_element_set_clock(). Some elements can provide a clock for the pipeline if gst_element_provides_clock() returns %TRUE. With the gst_element_provide_clock() method one can retrieve the clock provided by such an element. Not all elements require a clock to operate correctly. If gst_element_requires_clock() returns %TRUE, a clock should be set on the element with gst_element_set_clock(). Note that clock slection and distribution is normally handled by the toplevel #GstPipeline so the clock functions are only to be used in very specific situations. Last reviewed on 2009-05-29 (0.10.24)

Signals

void"no-more-pads"(self, element)

This signals that the element will not generate more dynamic pads. Note that this signal will usually be emitted from the context of the streaming thread.

void"pad-removed"(self, element, old_pad)

a #GstPad has been removed from the element

void"pad-added"(self, element, new_pad)

a new #GstPad has been added to the element. Note that this signal will usually be emitted from the context of the streaming thread. Also keep in mind that if you add new elements to the pipeline in the signal handler you will need to set them to the desired target state with gst_element_set_state() or gst_element_sync_state_with_parent().

Methods

voidabort_state()

booladd_pad(pad)

Gst.StateChangeReturncontinue_state(ret)

voidcreate_all_pads()

voidfound_tags(list)

voidfound_tags_for_pad(pad, list)

Gst.ClockTimeget_base_time()

Gst.Busget_bus()

Gst.Clockget_clock()

Gst.Padget_compatible_pad(pad, caps)

Gst.PadTemplateget_compatible_pad_template(compattempl)

Gst.ElementFactoryget_factory()

Gst.Indexget_index()

Gst.Padget_pad(name)

Gst.QueryTypeget_query_types()

Gst.Padget_request_pad(name)

Gst.ClockTimeget_start_time()

Gst.Padget_static_pad(name)

boolimplements_interface(iface_type)

boolis_indexable()

boolis_locked_state()

boollink(dest)

boollink_filtered(dest, filter)

boollink_pads(srcpadname, dest, destpadname)

boollink_pads_filtered(srcpadname, dest, destpadname, filter)

boollink_pads_full(srcpadname, dest, destpadname, flags)

voidlost_state()

voidlost_state_full(new_base_time)

Gst.Elementmake_from_uri(type, uri, elementname)(static method)

voidmessage_full(type, domain, code, text, debug, file, function, line)

voidno_more_pads()

voidpad_added(pad)

voidpad_removed(pad)

boolpost_message(message)

Gst.Clockprovide_clock()

boolprovides_clock()

boolquery(query)

bool, intquery_convert(src_format, src_val, dest_format)

bool, intquery_duration(format)

bool, intquery_position(format)

boolregister(plugin, name, rank, type)(static method)

voidrelease_pad(pad)

voidrelease_request_pad(pad)

boolremove_pad(pad)

Gst.Padrequest_pad(templ, name, caps)

boolrequires_clock()

boolseek(rate, format, flags, cur_type, cur, stop_type, stop)

boolseek_simple(format, seek_flags, seek_pos)

boolsend_event(event)

voidset_base_time(time)

voidset_bus(bus)

boolset_clock(clock)

voidset_index(index)

boolset_locked_state(locked_state)

voidset_start_time(time)

stringstate_change_return_get_name(state_ret)(static method)

stringstate_get_name(state)(static method)

boolsync_state_with_parent()

voidunlink(dest)

voidunlink_pads(srcpadname, dest, destpadname)

Class: Gst.ElementFactory

Subclass of: Gst.PluginFeature

#GstElementFactory is used to create instances of elements. A GstElementfactory can be added to a #GstPlugin as it is also a #GstPluginFeature. Use the gst_element_factory_find() and gst_element_factory_create() functions to create element instances or use gst_element_factory_make() as a convenient shortcut. The following code example shows you how to create a GstFileSrc element. <example> <title>Using an element factory</title> <programlisting language="c"> #include &lt;gst/gst.h&gt; GstElement *src; GstElementFactory *srcfactory; gst_init (&amp;argc, &amp;argv); srcfactory = gst_element_factory_find ("filesrc"); g_return_if_fail (srcfactory != NULL); src = gst_element_factory_create (srcfactory, "src"); g_return_if_fail (src != NULL); ... </programlisting> </example> Last reviewed on 2005-11-23 (0.9.5)

Methods

boolcan_sink_all_caps(caps)

boolcan_sink_any_caps(caps)

boolcan_sink_caps(caps)

boolcan_src_all_caps(caps)

boolcan_src_any_caps(caps)

boolcan_src_caps(caps)

Gst.Elementcreate(name)

Gst.ElementFactoryfind(name)(static method)

stringget_author()

stringget_description()

stringget_documentation_uri()

GTypeget_element_type()

stringget_icon_name()

stringget_klass()

stringget_longname()

intget_num_pad_templates()

GLib.Listget_static_pad_templates()

Arrayget_uri_protocols()

intget_uri_type()

boolhas_interface(interfacename)

GLib.Listlist_filter(list, caps, direction, subsetonly)(static method)

GLib.Listlist_get_elements(type, minrank)(static method)

boollist_is_type(type)

Gst.Elementmake(factoryname, name)(static method)

Class: Gst.Event

Subclass of: Gst.MiniObject

The event class provides factory methods to construct events for sending and functions to query (parse) received events. Events are usually created with gst_event_new_*() which takes event-type specific parameters as arguments. To send an event application will usually use gst_element_send_event() and elements will use gst_pad_send_event() or gst_pad_push_event(). The event should be unreffed with gst_event_unref() if it has not been sent. Events that have been received can be parsed with their respective gst_event_parse_*() functions. It is valid to pass %NULL for unwanted details. Events are passed between elements in parallel to the data stream. Some events are serialized with buffers, others are not. Some events only travel downstream, others only upstream. Some events can travel both upstream and downstream. The events are used to signal special conditions in the datastream such as EOS (end of stream) or the start of a new stream-segment. Events are also used to flush the pipeline of any pending data. Most of the event API is used inside plugins. Applications usually only construct and use seek events. To do that gst_event_new_seek() is used to create a seek event. It takes the needed parameters to specity seeking time and mode. <example> <title>performing a seek on a pipeline</title> <programlisting> GstEvent *event; gboolean result; ... // construct a seek event to play the media from second 2 to 5, flush // the pipeline to decrease latency. event = gst_event_new_seek (1.0, GST_FORMAT_TIME, GST_SEEK_FLAG_FLUSH, GST_SEEK_TYPE_SET, 2 * GST_SECOND, GST_SEEK_TYPE_SET, 5 * GST_SECOND); ... result = gst_element_send_event (pipeline, event); if (!result) g_warning ("seek failed"); ... </programlisting> </example> Last reviewed on 2006-09-6 (0.10.10)

Methods

intget_seqnum()

Gst.Structureget_structure()

boolhas_name(name)

void, Gst.Format, int, int, boolparse_buffer_size()

void, Gst.ClockTimeparse_latency()

void, bool, float, Gst.Format, int, int, intparse_new_segment()

void, bool, float, float, Gst.Format, int, int, intparse_new_segment_full()

void, float, Gst.ClockTimeDiff, Gst.ClockTimeparse_qos()

void, Gst.QOSType, float, Gst.ClockTimeDiff, Gst.ClockTimeparse_qos_full()

void, float, Gst.Format, Gst.SeekFlags, Gst.SeekType, int, Gst.SeekType, intparse_seek()

void, Gst.Messageparse_sink_message()

void, Gst.Format, int, float, bool, boolparse_step()

void, Gst.TagListparse_tag()

voidset_seqnum(seqnum)

Gst.EventTypeFlagstype_get_flags(type)(static method)

stringtype_get_name(type)(static method)

GLib.Quarktype_to_quark(type)(static method)

Class: Gst.GhostPad

Subclass of: Gst.ProxyPad

GhostPads are useful when organizing pipelines with #GstBin like elements. The idea here is to create hierarchical element graphs. The bin element contains a sub-graph. Now one would like to treat the bin-element like any other #GstElement. This is where GhostPads come into play. A GhostPad acts as a proxy for another pad. Thus the bin can have sink and source ghost-pads that are associated with sink and source pads of the child elements. If the target pad is known at creation time, gst_ghost_pad_new() is the function to use to get a ghost-pad. Otherwise one can use gst_ghost_pad_new_no_target() to create the ghost-pad and use gst_ghost_pad_set_target() to establish the association later on. Note that GhostPads add overhead to the data processing of a pipeline. Last reviewed on 2005-11-18 (0.9.5)

Methods

boolconstruct()

Gst.Padget_target()

boolset_target(newtarget)

Interface: Gst.ImplementsInterface

Provides interface functionality on per instance basis and not per class basis, which is the case for gobject.

Class: Gst.Index

Subclass of: Gst.Object

GstIndex is used to generate a stream index of one or more elements in a pipeline. Elements will overload the set_index and get_index virtual methods in #GstElement. When streaming data, the element will add index entries if it has an index set. Each element that adds to the index will do that using a writer_id. The writer_id is obtained from gst_index_get_writer_id(). The application that wants to index the stream will create a new index object using gst_index_new() or gst_index_factory_make(). The index is assigned to a specific element, a bin or the whole pipeline. This will cause indexable elements to add entires to the index while playing.

Properties

unknown_{http://www.gtk.org/introspection/core/1.0}type"resolver"read/write

Signals

void"entry-added"(self, index, arg1)

Is emitted when a new entry is added to the index.

Methods

Gst.IndexEntryadd_associationv(id, flags, n, list)

voidadd_entry(entry)

Gst.IndexEntryadd_format(id, format)

Gst.IndexEntryadd_id(id, description)

Gst.IndexEntryadd_object(id, key, type, object)

voidcommit(id)

voidentry_added(entry)

Gst.IndexCertaintyget_certainty()

intget_group()

boolget_writer_id(writer_id, writer_string)

intnew_group()

voidset_certainty(certainty)

voidset_filter_full(filter, user_data, user_data_destroy)

boolset_group(groupnum)

voidset_resolver_full(resolver, user_data, user_data_destroy)

Class: Gst.IndexFactory

Subclass of: Gst.PluginFeature

GstIndexFactory is used to dynamically create GstIndex implementations.

Methods

Gst.Indexcreate()

voiddestroy()

Gst.IndexFactoryfind(name)(static method)

Gst.Indexmake(name)(static method)

Class: Gst.Message

Subclass of: Gst.MiniObject

Messages are implemented as a subclass of #GstMiniObject with a generic #GstStructure as the content. This allows for writing custom messages without requiring an API change while allowing a wide range of different types of messages. Messages are posted by objects in the pipeline and are passed to the application using the #GstBus. The basic use pattern of posting a message on a #GstBus is as follows: <example> <title>Posting a #GstMessage</title> <programlisting> gst_bus_post (bus, gst_message_new_eos()); </programlisting> </example> A #GstElement usually posts messages on the bus provided by the parent container using gst_element_post_message(). Last reviewed on 2005-11-09 (0.9.4)

Methods

intget_seqnum()

GObject.Valueget_stream_status_object()

Gst.Structureget_structure()

void, boolparse_async_start()

void, intparse_buffering()

void, Gst.BufferingMode, int, int, intparse_buffering_stats()

void, Gst.Clockparse_clock_lost()

void, Gst.Clock, boolparse_clock_provide()

void, Gst.Format, intparse_duration()

void, GLib.Error, stringparse_error()

void, GLib.Error, stringparse_info()

void, Gst.Clockparse_new_clock()

void, Gst.ProgressType, string, stringparse_progress()

void, bool, int, int, int, intparse_qos()

void, Gst.Format, int, intparse_qos_stats()

void, int, float, intparse_qos_values()

void, Gst.Stateparse_request_state()

void, Gst.Format, intparse_segment_done()

void, Gst.Format, intparse_segment_start()

void, Gst.State, Gst.State, Gst.Stateparse_state_changed()

void, Gst.Format, int, float, bool, bool, int, boolparse_step_done()

void, bool, Gst.Format, int, float, bool, boolparse_step_start()

void, Gst.StreamStatusType, Gst.Elementparse_stream_status()

void, Gst.StructureChangeType, Gst.Element, boolparse_structure_change()

void, Gst.TagListparse_tag()

void, Gst.Pad, Gst.TagListparse_tag_full()

void, GLib.Error, stringparse_warning()

voidset_buffering_stats(mode, avg_in, avg_out, buffering_left)

voidset_qos_stats(format, processed, dropped)

voidset_qos_values(jitter, proportion, quality)

voidset_seqnum(seqnum)

voidset_stream_status_object(object)

stringtype_get_name(type)(static method)

GLib.Quarktype_to_quark(type)(static method)

Abstract Class: Gst.MiniObject

Known subclasses: Gst.BufferList, Gst.Query, Gst.Message, Gst.Event, Gst.Buffer

#GstMiniObject is a baseclass like #GObject, but has been stripped down of features to be fast and small. It offers sub-classing and ref-counting in the same way as #GObject does. It has no properties and no signal-support though. Last reviewed on 2005-11-23 (0.9.5)

Methods

boolis_writable()

Gst.MiniObjectmake_writable()

voidreplace(olddata, newdata)(static method)

voidunref()

Abstract Class: Gst.Object

Known subclasses: Gst.Clock, Gst.Bus, Gst.PadTemplate, Gst.XML, Gst.Task, Gst.Pad, Gst.Plugin, Gst.Index, Gst.Element, Gst.Registry, Gst.PluginFeature, Gst.TaskPool

#GstObject provides a root for the object hierarchy tree filed in by the GStreamer library. It is currently a thin wrapper on top of #GObject. It is an abstract class that is not very usable on its own. #GstObject gives us basic refcounting, parenting functionality and locking. Most of the function are just extended for special GStreamer needs and can be found under the same name in the base class of #GstObject which is #GObject (e.g. g_object_ref() becomes gst_object_ref()). The most interesting difference between #GstObject and #GObject is the "floating" reference count. A #GObject is created with a reference count of 1, owned by the creator of the #GObject. (The owner of a reference is the code section that has the right to call gst_object_unref() in order to remove that reference.) A #GstObject is created with a reference count of 1 also, but it isn't owned by anyone; Instead, the initial reference count of a #GstObject is "floating". The floating reference can be removed by anyone at any time, by calling gst_object_sink(). gst_object_sink() does nothing if an object is already sunk (has no floating reference). When you add a #GstElement to its parent container, the parent container will do this: <informalexample> <programlisting> gst_object_ref (GST_OBJECT (child_element)); gst_object_sink (GST_OBJECT (child_element)); </programlisting> </informalexample> This means that the container now owns a reference to the child element (since it called gst_object_ref()), and the child element has no floating reference. The purpose of the floating reference is to keep the child element alive until you add it to a parent container, which then manages the lifetime of the object itself: <informalexample> <programlisting> element = gst_element_factory_make (factoryname, name); // element has one floating reference to keep it alive gst_bin_add (GST_BIN (bin), element); // element has one non-floating reference owned by the container </programlisting> </informalexample> Another effect of this is, that calling gst_object_unref() on a bin object, will also destoy all the #GstElement objects in it. The same is true for calling gst_bin_remove(). Special care has to be taken for all methods that gst_object_sink() an object since if the caller of those functions had a floating reference to the object, the object reference is now invalid. In contrast to #GObject instances, #GstObject adds a name property. The functions gst_object_set_name() and gst_object_get_name() are used to set/get the name of the object. Last reviewed on 2005-11-09 (0.9.4)

Properties

string"name"construct-only

Signals

void"object-saved"(self, object, xml_node)

Trigered whenever a new object is saved to XML. You can connect to this signal to insert custom XML tags into the core XML.

void"deep-notify"(self, object, prop_object, prop)

The deep notify signal is used to be notified of property changes. It is typically attached to the toplevel bin to receive notifications from all the elements contained in that bin.

void"parent-unset"(self, object, parent)

Emitted when the parent of an object is unset.

void"parent-set"(self, object, parent)

Emitted when the parent of an object is set.

Methods

boolcheck_uniqueness(list, name)(static method)

voiddeep_notify(orig, pspec)

voiddefault_deep_notify(object, orig, pspec, excluded_props)(static method)

voiddefault_error(error, debug)

stringget_name()

stringget_name_prefix()

Gst.Objectget_parent()

stringget_path_string()

boolhas_ancestor(ancestor)

voidobject_saved(parent)

voidparent_set(parent)

voidparent_unset(parent)

gpointerref(object)(static method)

voidref_sink(object)(static method)

voidreplace(oldobj, newobj)(static method)

voidrestore_thyself(self)

boolset_name(name)

voidset_name_prefix(name_prefix)

boolset_parent(parent)

voidsink(object)(static method)

voidunparent()

voidunref(object)(static method)

Class: Gst.Pad

Known subclasses: Gst.ProxyPad

Subclass of: Gst.Object

A #GstElement is linked to other elements via "pads", which are extremely light-weight generic link points. After two pads are retrieved from an element with gst_element_get_pad(), the pads can be link with gst_pad_link(). (For quick links, you can also use gst_element_link(), which will make the obvious link for you if it's straightforward.) Pads are typically created from a #GstPadTemplate with gst_pad_new_from_template(). Pads have #GstCaps attached to it to describe the media type they are capable of dealing with. gst_pad_get_caps() and gst_pad_set_caps() are used to manipulate the caps of the pads. Pads created from a pad template cannot set capabilities that are incompatible with the pad template capabilities. Pads without pad templates can be created with gst_pad_new(), which takes a direction and a name as an argument. If the name is NULL, then a guaranteed unique name will be assigned to it. gst_pad_get_parent() will retrieve the #GstElement that owns the pad. A #GstElement creating a pad will typically use the various gst_pad_set_*_function() calls to register callbacks for various events on the pads. GstElements will use gst_pad_push() and gst_pad_pull_range() to push out or pull in a buffer. To send a #GstEvent on a pad, use gst_pad_send_event() and gst_pad_push_event(). Last reviewed on 2006-07-06 (0.10.9)

Properties

unknown_{http://www.gtk.org/introspection/core/1.0}type"direction"construct-only

Gst.PadTemplate"template"read/write

Gst.Caps"caps"read-only

Signals

void"request-link"(self, pad)

Signals that a pad connection has been requested.

void"unlinked"(self, pad, peer)

Signals that a pad has been unlinked from the peer pad.

bool"have-data"(self, pad, mini_obj)

Signals that new data is available on the pad. This signal is used internally for implementing pad probes. See gst_pad_add_*_probe functions.

void"linked"(self, pad, peer)

Signals that a pad has been linked to the peer pad.

Methods

boolaccept_caps(caps)

boolactivate_pull(active)

boolactivate_push(active)

intadd_buffer_probe_full(handler, data, notify)

intadd_data_probe_full(handler, data, notify)

intadd_event_probe_full(handler, data, notify)

Gst.FlowReturnalloc_buffer(offset, size, caps, buf)

Gst.FlowReturn, Gst.Bufferalloc_buffer_and_set_caps(offset, size, caps)

boolcan_link(sinkpad)

Gst.FlowReturnchain_list(list)

boolcheck_pull_range()

boolevent_default(event)

voidfixate_caps(caps)

Gst.Capsget_allowed_caps()

Gst.Capsget_caps()

Gst.Capsget_caps_reffed()

Gst.PadDirectionget_direction()

gpointerget_element_private()

Gst.Capsget_fixed_caps_func()

GLib.Listget_internal_links()

GLib.Listget_internal_links_default()

Gst.Capsget_negotiated_caps()

Gst.PadTemplateget_pad_template()

Gst.Capsget_pad_template_caps()

Gst.Elementget_parent_element()

Gst.Padget_peer()

Arrayget_query_types()

Arrayget_query_types_default()

Gst.FlowReturn, Gst.Bufferget_range(offset, size)

boolhave_data(data)

boolis_active()

boolis_blocked()

boolis_blocking()

boolis_linked()

voidlinked(peer)

voidload_and_link(self, parent)(static method)

boolpause_task()

boolpeer_accept_caps(caps)

Gst.Capspeer_get_caps()

Gst.Capspeer_get_caps_reffed()

boolpeer_query(query)

Gst.Capsproxy_getcaps()

boolproxy_setcaps(caps)

Gst.FlowReturn, Gst.Bufferpull_range(offset, size)

boolpush_event(event)

Gst.FlowReturnpush_list(list)

boolquery(query)

bool, intquery_convert(src_format, src_val, dest_format)

boolquery_default(query)

bool, intquery_duration(format)

bool, intquery_peer_convert(src_format, src_val, dest_format)

bool, intquery_peer_duration(format)

bool, intquery_peer_position(format)

bool, intquery_position(format)

voidremove_buffer_probe(handler_id)

voidremove_data_probe(handler_id)

voidremove_event_probe(handler_id)

voidrequest_link()

boolsend_event(event)

boolset_active(active)

boolset_blocked(blocked)

boolset_blocked_async_full(blocked, callback, user_data, destroy_data)

boolset_caps(caps)

voidset_element_private(priv)

boolstop_task()

boolunlink(sinkpad)

voidunlinked(peer)

voiduse_fixed_caps()

Class: Gst.PadTemplate

Subclass of: Gst.Object

Padtemplates describe the possible media types a pad or an elementfactory can handle. This allows for both inspection of handled types before loading the element plugin as well as identifying pads on elements that are not yet created (request or sometimes pads). Pad and PadTemplates have #GstCaps attached to it to describe the media type they are capable of dealing with. gst_pad_template_get_caps() or GST_PAD_TEMPLATE_CAPS() are used to get the caps of a padtemplate. It's not possible to modify the caps of a padtemplate after creation. PadTemplates have a #GstPadPresence property which identifies the lifetime of the pad and that can be retrieved with GST_PAD_TEMPLATE_PRESENCE(). Also the direction of the pad can be retrieved from the #GstPadTemplate with GST_PAD_TEMPLATE_DIRECTION(). The GST_PAD_TEMPLATE_NAME_TEMPLATE () is important for GST_PAD_REQUEST pads because it has to be used as the name in the gst_element_get_request_pad() call to instantiate a pad from this template. Padtemplates can be created with gst_pad_template_new() or with gst_static_pad_template_get (), which creates a #GstPadTemplate from a #GstStaticPadTemplate that can be filled with the convenient GST_STATIC_PAD_TEMPLATE() macro. A padtemplate can be used to create a pad (see gst_pad_new_from_template() or gst_pad_new_from_static_template ()) or to add to an element class (see gst_element_class_add_pad_template ()). The following code example shows the code to create a pad from a padtemplate. <example> <title>Create a pad from a padtemplate</title> <programlisting> GstStaticPadTemplate my_template = GST_STATIC_PAD_TEMPLATE ( "sink", // the name of the pad GST_PAD_SINK, // the direction of the pad GST_PAD_ALWAYS, // when this pad will be present GST_STATIC_CAPS ( // the capabilities of the padtemplate "audio/x-raw-int, " "channels = (int) [ 1, 6 ]" ) ); void my_method (void) { GstPad *pad; pad = gst_pad_new_from_static_template (&amp;my_template, "sink"); ... } </programlisting> </example> The following example shows you how to add the padtemplate to an element class, this is usually done in the base_init of the class: <informalexample> <programlisting> static void my_element_base_init (gpointer g_class) { GstElementClass *gstelement_class = GST_ELEMENT_CLASS (g_class); gst_element_class_add_pad_template (gstelement_class, gst_static_pad_template_get (&amp;my_template)); } </programlisting> </informalexample> Last reviewed on 2006-02-14 (0.10.3)

Properties

string"name-template"construct-only

The name template of the pad template.

unknown_{http://www.gtk.org/introspection/core/1.0}type"direction"construct-only

The direction of the pad described by the pad template.

unknown_{http://www.gtk.org/introspection/core/1.0}type"presence"construct-only

When the pad described by the pad template will become available.

Gst.Caps"caps"construct-only

The capabilities of the pad described by the pad template.

Signals

void"pad-created"(self, pad_template, pad)

This signal is fired when an element creates a pad from this template.

Methods

Gst.Capsget_caps()

voidpad_created(pad)

Class: Gst.ParamFraction

Methods

Class: Gst.Pipeline

Implements: Gst.ChildProxy

Subclass of: Gst.Bin

A #GstPipeline is a special #GstBin used as the toplevel container for the filter graph. The #GstPipeline will manage the selection and distribution of a global #GstClock as well as provide a #GstBus to the application. It will also implement a default behavour for managing seek events (see gst_element_seek()). gst_pipeline_new() is used to create a pipeline. when you are done with the pipeline, use gst_object_unref() to free its resources including all added #GstElement objects (if not otherwise referenced). Elements are added and removed from the pipeline using the #GstBin methods like gst_bin_add() and gst_bin_remove() (see #GstBin). Before changing the state of the #GstPipeline (see #GstElement) a #GstBus can be retrieved with gst_pipeline_get_bus(). This bus can then be used to receive #GstMessage from the elements in the pipeline. By default, a #GstPipeline will automatically flush the pending #GstBus messages when going to the NULL state to ensure that no circular references exist when no messages are read from the #GstBus. This behaviour can be changed with gst_pipeline_set_auto_flush_bus(). When the #GstPipeline performs the PAUSED to PLAYING state change it will select a clock for the elements. The clock selection algorithm will by default select a clock provided by an element that is most upstream (closest to the source). For live pipelines (ones that return #GST_STATE_CHANGE_NO_PREROLL from the gst_element_set_state() call) this will select the clock provided by the live source. For normal pipelines this will select a clock provided by the sinks (most likely the audio sink). If no element provides a clock, a default #GstSystemClock is used. The clock selection can be controlled with the gst_pipeline_use_clock() method, which will enforce a given clock on the pipeline. With gst_pipeline_auto_clock() the default clock selection algorithm can be restored. A #GstPipeline maintains a running time for the elements. The running time is defined as the difference between the current clock time and the base time. When the pipeline goes to READY or a flushing seek is performed on it, the running time is reset to 0. When the pipeline is set from PLAYING to PAUSED, the current clock time is sampled and used to configure the base time for the elements when the pipeline is set to PLAYING again. The effect is that the running time (as the difference between the clock time and the base time) will count how much time was spent in the PLAYING state. This default behaviour can be changed with the gst_element_set_start_time() method. When sending a flushing seek event to a GstPipeline (see gst_element_seek()), it will make sure that the pipeline is properly PAUSED and resumed as well as set the new running time to 0 when the seek succeeded. Last reviewed on 2009-05-29 (0.10.24)

Properties

int"delay"read/write

The expected delay needed for elements to spin up to the PLAYING state expressed in nanoseconds. see gst_pipeline_set_delay() for more information on this option.

bool"auto-flush-bus"read/write

Whether or not to automatically flush all messages on the pipeline's bus when going from READY to NULL state. Please see gst_pipeline_set_auto_flush_bus() for more information on this option.

Methods

voidauto_clock()

boolget_auto_flush_bus()

Gst.Busget_bus()

Gst.Clockget_clock()

Gst.ClockTimeget_delay()

Gst.ClockTimeget_last_stream_time()

voidset_auto_flush_bus(auto_flush)

boolset_clock(clock)

voidset_delay(delay)

voidset_new_stream_time(time)

voiduse_clock(clock)

Class: Gst.Plugin

Subclass of: Gst.Object

GStreamer is extensible, so #GstElement instances can be loaded at runtime. A plugin system can provide one or more of the basic <application>GStreamer</application> #GstPluginFeature subclasses. A plugin should export a symbol <symbol>gst_plugin_desc</symbol> that is a struct of type #GstPluginDesc. the plugin loader will check the version of the core library the plugin was linked against and will create a new #GstPlugin. It will then call the #GstPluginInitFunc function that was provided in the <symbol>gst_plugin_desc</symbol>. Once you have a handle to a #GstPlugin (e.g. from the #GstRegistry), you can add any object that subclasses #GstPluginFeature. Usually plugins are always automaticlly loaded so you don't need to call gst_plugin_load() explicitly to bring it into memory. There are options to statically link plugins to an app or even use GStreamer without a plugin repository in which case gst_plugin_load() can be needed to bring the plugin into memory.

Methods

voidadd_dependency(env_vars, paths, names, flags)

voidadd_dependency_simple(env_vars, paths, names, flags)

GLib.Quarkerror_quark()(static method)

Gst.Structureget_cache_data()

stringget_description()

stringget_filename()

stringget_license()

GModule.Moduleget_module()

stringget_name()

stringget_origin()

stringget_package()

stringget_source()

stringget_version()

boolis_loaded()

voidlist_free(list)(static method)

Gst.Pluginload()

Gst.Pluginload_by_name(name)(static method)

Gst.Pluginload_file(filename)(static method)

boolname_filter(name)

boolregister_static(major_version, minor_version, name, description, init_func, version, license, source, package, origin)(static method)

boolregister_static_full(major_version, minor_version, name, description, init_full_func, version, license, source, package, origin, user_data)(static method)

voidset_cache_data(cache_data)

Abstract Class: Gst.PluginFeature

Known subclasses: Gst.TypeFindFactory, Gst.IndexFactory, Gst.ElementFactory

Subclass of: Gst.Object

This is a base class for anything that can be added to a #GstPlugin.

Methods

boolcheck_version(min_major, min_minor, min_micro)

stringget_name()

intget_rank()

GLib.Listlist_copy(list)(static method)

voidlist_debug(list)(static method)

voidlist_free(list)(static method)

intrank_compare_func(p1, p2)(static method)

voidset_name(name)

voidset_rank(rank)

booltype_name_filter(data)

Interface: Gst.Preset

This interface offers methods to query and manipulate parameter preset sets. A preset is a bunch of property settings, together with meta data and a name. The name of a preset serves as key for subsequent method calls to manipulate single presets. All instances of one type will share the list of presets. The list is created on demand, if presets are not used, the list is not created. The interface comes with a default implementation that serves most plugins. Wrapper plugins will override most methods to implement support for the native preset format of those wrapped plugins. One method that is useful to be overridden is gst_preset_get_property_names(). With that one can control which properties are saved and in which order.

Methods

booldelete_preset(name)

bool, stringget_meta(name, tag)

Arrayget_preset_names()

Arrayget_property_names()

boolload_preset(name)

boolrename_preset(old_name, new_name)

boolsave_preset(name)

boolset_meta(name, tag, value)

Class: Gst.ProxyPad

Known subclasses: Gst.GhostPad

Subclass of: Gst.Pad

Class: Gst.Query

Subclass of: Gst.MiniObject

GstQuery functions are used to register new query types to the gstreamer core and use them. Queries can be performed on pads (gst_pad_query()) and elements (gst_element_query()). Please note that some queries might need a running pipeline to work. Queries can be created using the gst_query_new_*() functions. Query values can be set using gst_query_set_*(), and parsed using gst_query_parse_*() helpers. The following example shows how to query the duration of a pipeline: <example> <title>Query duration on a pipeline</title> <programlisting> GstQuery *query; gboolean res; query = gst_query_new_duration (GST_FORMAT_TIME); res = gst_element_query (pipeline, query); if (res) { gint64 duration; gst_query_parse_duration (query, NULL, &amp;duration); g_print ("duration = %"GST_TIME_FORMAT, GST_TIME_ARGS (duration)); } else { g_print ("duration query failed..."); } gst_query_unref (query); </programlisting> </example> Last reviewed on 2006-02-14 (0.10.4)

Methods

booladd_buffering_range(start, stop)

intget_n_buffering_ranges()

Gst.Structureget_structure()

void, bool, intparse_buffering_percent()

void, Gst.Format, int, int, intparse_buffering_range()

void, Gst.BufferingMode, int, int, intparse_buffering_stats()

void, Gst.Format, int, Gst.Format, intparse_convert()

void, Gst.Format, intparse_duration()

void, intparse_formats_length()

void, int, Gst.Formatparse_formats_nth()

void, bool, Gst.ClockTime, Gst.ClockTimeparse_latency()

bool, int, intparse_nth_buffering_range(index)

void, Gst.Format, intparse_position()

void, Gst.Format, bool, int, intparse_seeking()

void, float, Gst.Format, int, intparse_segment()

void, stringparse_uri()

voidset_buffering_percent(busy, percent)

voidset_buffering_range(format, start, stop, estimated_total)

voidset_buffering_stats(mode, avg_in, avg_out, buffering_left)

voidset_convert(src_format, src_value, dest_format, dest_value)

voidset_duration(format, duration)

voidset_formatsv(n_formats, formats)

voidset_latency(live, min_latency, max_latency)

voidset_position(format, cur)

voidset_seeking(format, seekable, segment_start, segment_end)

voidset_segment(rate, format, start_value, stop_value)

voidset_uri(uri)

Gst.QueryTypetype_get_by_nick(nick)(static method)

Gst.QueryTypeDefinitiontype_get_details(type)(static method)

stringtype_get_name(query)(static method)

Gst.QueryTypetype_register(nick, description)(static method)

GLib.Quarktype_to_quark(query)(static method)

booltypes_contains(types, type)(static method)

Class: Gst.Registry

Subclass of: Gst.Object

One registry holds the metadata of a set of plugins. <emphasis role="bold">Design:</emphasis> The #GstRegistry object is a list of plugins and some functions for dealing with them. Each #GstPlugin is matched 1-1 with a file on disk, and may or may not be loaded at a given time. There may be multiple #GstRegistry objects, but the "default registry" is the only object that has any meaning to the core. The registry file is actually a cache of plugin information. This is unlike versions prior to 0.10, where the registry file was the primary source of plugin information, and was created by the gst-register command. The primary source, at all times, of plugin information is each plugin file itself. Thus, if an application wants information about a particular plugin, or wants to search for a feature that satisfies given criteria, the primary means of doing so is to load every plugin and look at the resulting information that is gathered in the default registry. Clearly, this is a time consuming process, so we cache information in the registry file. The format and location of the cache file is internal to gstreamer. On startup, plugins are searched for in the plugin search path. The following locations are checked in this order: <itemizedlist> <listitem> <para>location from --gst-plugin-path commandline option.</para> </listitem> <listitem> <para>the GST_PLUGIN_PATH environment variable.</para> </listitem> <listitem> <para>the GST_PLUGIN_SYSTEM_PATH environment variable.</para> </listitem> <listitem> <para>default locations (if GST_PLUGIN_SYSTEM_PATH is not set). Those default locations are: <filename>~/.gstreamer-$GST_MAJORMINOR/plugins/</filename> and <filename>$prefix/libs/gstreamer-$GST_MAJORMINOR/</filename>. </para> </listitem> </itemizedlist> The registry cache file is loaded from <filename>~/.gstreamer-$GST_MAJORMINOR/registry-$ARCH.bin</filename> or the file listed in the GST_REGISTRY env var. One reason to change the registry location is for testing. For each plugin that is found in the plugin search path, there could be 3 possibilities for cached information: <itemizedlist> <listitem> <para>the cache may not contain information about a given file.</para> </listitem> <listitem> <para>the cache may have stale information.</para> </listitem> <listitem> <para>the cache may have current information.</para> </listitem> </itemizedlist> In the first two cases, the plugin is loaded and the cache updated. In addition to these cases, the cache may have entries for plugins that are not relevant to the current process. These are marked as not available to the current process. If the cache is updated for whatever reason, it is marked dirty. A dirty cache is written out at the end of initialization. Each entry is checked to make sure the information is minimally valid. If not, the entry is simply dropped. <emphasis role="bold">Implementation notes:</emphasis> The "cache" and "default registry" are different concepts and can represent different sets of plugins. For various reasons, at init time, the cache is stored in the default registry, and plugins not relevant to the current process are marked with the %GST_PLUGIN_FLAG_CACHED bit. These plugins are removed at the end of intitialization.

Signals

void"plugin-added"(self, registry, plugin)

Signals that a plugin has been added to the registry (possibly replacing a previously-added one by the same name)

void"feature-added"(self, registry, feature)

Signals that a feature has been added to the registry (possibly replacing a previously-added one by the same name)

Methods

booladd_feature(feature)

voidadd_path(path)

booladd_plugin(plugin)

voidfeature_added(feature)

GLib.Listfeature_filter(filter, first, user_data)

Gst.PluginFeaturefind_feature(name, type)

Gst.Pluginfind_plugin(name)

boolfork_is_enabled()(static method)

voidfork_set_enabled(enabled)(static method)

Gst.Registryget_default()(static method)

GLib.Listget_feature_list(type)

GLib.Listget_feature_list_by_plugin(name)

intget_feature_list_cookie()

GLib.Listget_path_list()

GLib.Listget_plugin_list()

Gst.Pluginlookup(filename)

Gst.PluginFeaturelookup_feature(name)

voidplugin_added(plugin)

GLib.Listplugin_filter(filter, first, user_data)

voidremove_feature(feature)

voidremove_plugin(plugin)

boolscan_path(path)

boolxml_read_cache(location)

boolxml_write_cache(location)

Class: Gst.SystemClock

Subclass of: Gst.Clock

The GStreamer core provides a GstSystemClock based on the system time. Asynchronous callbacks are scheduled from an internal thread. Clock implementors are encouraged to subclass this systemclock as it implements the async notification. Subclasses can however override all of the important methods for sync and async notifications to implement their own callback methods or blocking wait operations. Last reviewed on 2006-03-08 (0.10.4)

Properties

unknown_{http://www.gtk.org/introspection/core/1.0}type"clock-type"read/write

Methods

Gst.Clockobtain()(static method)

Interface: Gst.TagSetter

Element interface that allows setting of media metadata. Elements that support changing a stream's metadata will implement this interface. Examples of such elements are 'vorbisenc', 'theoraenc' and 'id3v2mux'. If you just want to retrieve metadata in your application then all you need to do is watch for tag messages on your pipeline's bus. This interface is only for setting metadata, not for extracting it. To set tags from the application, find tagsetter elements and set tags using e.g. gst_tag_setter_merge_tags() or gst_tag_setter_add_tags(). Also consider setting the #GstTagMergeMode that is used for tag events that arrive at the tagsetter element (default mode is to keep existing tags). The application should do that before the element goes to %GST_STATE_PAUSED. Elements implementing the #GstTagSetter interface often have to merge any tags received from upstream and the tags set by the application via the interface. This can be done like this: |[ GstTagMergeMode merge_mode; const GstTagList *application_tags; const GstTagList *event_tags; GstTagSetter *tagsetter; GstTagList *result; tagsetter = GST_TAG_SETTER (element); merge_mode = gst_tag_setter_get_tag_merge_mode (tagsetter); application_tags = gst_tag_setter_get_tag_list (tagsetter); event_tags = (const GstTagList *) element->event_tags; GST_LOG_OBJECT (tagsetter, "merging tags, merge mode = %d", merge_mode); result = gst_tag_list_merge (application_tags, event_tags, merge_mode); ]| Last reviewed on 2006-05-18 (0.10.6)

Methods

voidadd_tag_value(mode, tag, value)

Gst.TagListget_tag_list()

Gst.TagMergeModeget_tag_merge_mode()

voidmerge_tags(list, mode)

voidreset_tags()

voidset_tag_merge_mode(mode)

Class: Gst.Task

Subclass of: Gst.Object

#GstTask is used by #GstElement and #GstPad to provide the data passing threads in a #GstPipeline. A #GstPad will typically start a #GstTask to push or pull data to/from the peer pads. Most source elements start a #GstTask to push data. In some cases a demuxer element can start a #GstTask to pull data from a peer element. This is typically done when the demuxer can perform random access on the upstream peer element for improved performance. Although convenience functions exist on #GstPad to start/pause/stop tasks, it might sometimes be needed to create a #GstTask manually if it is not related to a #GstPad. Before the #GstTask can be run, it needs a #GStaticRecMutex that can be set with gst_task_set_lock(). The task can be started, paused and stopped with gst_task_start(), gst_task_pause() and gst_task_stop() respectively or with the gst_task_set_state() function. A #GstTask will repeatedly call the #GstTaskFunction with the user data that was provided when creating the task with gst_task_create(). While calling the function it will acquire the provided lock. The provided lock is released when the task pauses or stops. Stopping a task with gst_task_stop() will not immediately make sure the task is not running anymore. Use gst_task_join() to make sure the task is completely stopped and the thread is stopped. After creating a #GstTask, use gst_object_unref() to free its resources. This can only be done it the task is not running anymore. Task functions can send a #GstMessage to send out-of-band data to the application. The application can receive messages from the #GstBus in its mainloop. For debugging perposes, the task will configure its object name as the thread name on Linux. Please note that the object name should be configured before the task is started; changing the object name after the task has been started, has no effect on the thread name. Last reviewed on 2010-03-15 (0.10.29)

Methods

voidcleanup_all()(static method)

Gst.TaskPoolget_pool()

Gst.TaskStateget_state()

booljoin()

boolpause()

voidset_lock(mutex)

voidset_pool(pool)

voidset_priority(priority)

boolset_state(state)

voidset_thread_callbacks(callbacks, user_data, notify)

boolstart()

boolstop()

Class: Gst.TaskPool

Subclass of: Gst.Object

This object provides an abstraction for creating threads. The default implementation uses a regular GThreadPool to start tasks. Subclasses can be made to create custom threads. Last reviewed on 2009-04-23 (0.10.24)

Methods

voidcleanup()

voidjoin(id)

voidprepare()

Class: Gst.TypeFindFactory

Subclass of: Gst.PluginFeature

These functions allow querying informations about registered typefind functions. How to create and register these functions is described in the section <link linkend="gstreamer-Writing-typefind-functions"> "Writing typefind functions"</link>. <example> <title>how to write a simple typefinder</title> <programlisting> typedef struct { guint8 *data; guint size; guint probability; GstCaps *data; } MyTypeFind; static void my_peek (gpointer data, gint64 offset, guint size) { MyTypeFind *find = (MyTypeFind *) data; if (offset &gt;= 0 &amp;&amp; offset + size &lt;= find->size) { return find->data + offset; } return NULL; } static void my_suggest (gpointer data, guint probability, GstCaps *caps) { MyTypeFind *find = (MyTypeFind *) data; if (probability &gt; find->probability) { find->probability = probability; gst_caps_replace (&amp;find->caps, caps); } } static GstCaps * find_type (guint8 *data, guint size) { GList *walk, *type_list; MyTypeFind find = {data, size, 0, NULL}; GstTypeFind gst_find = {my_peek, my_suggest, &amp;find, }; walk = type_list = gst_type_find_factory_get_list (); while (walk) { GstTypeFindFactory *factory = GST_TYPE_FIND_FACTORY (walk->data); walk = g_list_next (walk) gst_type_find_factory_call_function (factory, &amp;gst_find); } g_list_free (type_list); return find.caps; }; </programlisting> </example> The above example shows how to write a very simple typefinder that identifies the given data. You can get quite a bit more complicated than that though. Last reviewed on 2005-11-09 (0.9.4)

Methods

voidcall_function(find)

Gst.Capsget_caps()

Arrayget_extensions()

GLib.Listget_list()(static method)

Interface: Gst.URIHandler

The URIHandler is an interface that is implemented by Source and Sink #GstElement to simplify then handling of URI. An application can use the following functions to quickly get an element that handles the given URI for reading or writing (gst_element_make_from_uri()). Source and Sink plugins should implement this interface when possible. Last reviewed on 2005-11-09 (0.9.4)

Signals

none"new-uri"(self, urihandler, uri)

The URI of the given @handler has changed.

Methods

Arrayget_protocols()

intget_uri_type()

stringget_uri()

voidnew_uri(uri)

boolset_uri(uri)

Class: Gst.XML

Subclass of: Gst.Object

GStreamer pipelines can be saved to xml files using gst_xml_write_file(). They can be loaded back using gst_xml_parse_doc() / gst_xml_parse_file() / gst_xml_parse_memory(). Additionally one can load saved pipelines into the gst-editor to inspect the graph. #GstElement implementations need to override the #GstObjectClass.save_thyself() and #GstObjectClass.restore_thyself() virtual functions of #GstObject. broken for all but the most simple pipelines. It will most likely be removed in future. Don't use it.

Signals

void"object-loaded"(self, xml, object, xml_node)

Signals that a new object has been deserialized.

Methods

voidobject_loaded(object, self)

voidobject_saved(object, self)

boolparse_doc(doc, root)

boolparse_file(fname, root)

boolparse_memory(buffer, size, root)

intwrite_file(element, out)(static method)