mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-24 09:10:36 +00:00
parent
bf8e36a768
commit
24428e9326
5 changed files with 8 additions and 8 deletions
|
@ -117,7 +117,7 @@
|
|||
</para>
|
||||
<para>
|
||||
The buffer contains one or more <classname>GstMemory</classname>
|
||||
objects thet represent the data in the buffer.
|
||||
objects that represent the data in the buffer.
|
||||
</para>
|
||||
<para>
|
||||
Metadata in the buffer consists of:
|
||||
|
@ -398,7 +398,7 @@ my_example_meta_api_get_type (void)
|
|||
macro. You will also make a method to add your metadata
|
||||
implementation to a <classname>GstBuffer</classname>.
|
||||
Your <filename>my-example-meta.h</filename> header file will
|
||||
need thse additions:
|
||||
need these additions:
|
||||
</para>
|
||||
<programlisting>
|
||||
<![CDATA[
|
||||
|
|
|
@ -64,7 +64,7 @@
|
|||
<title> Buffer running-time </title>
|
||||
<para>
|
||||
To calculate a buffer running-time, we need a buffer timestamp and
|
||||
the SEGMENT event that preceeded the buffer. First we can convert
|
||||
the SEGMENT event that preceded the buffer. First we can convert
|
||||
the SEGMENT event into a <classname>GstSegment</classname> object
|
||||
and then we can use the
|
||||
<function>gst_segment_to_running_time ()</function> function to
|
||||
|
|
|
@ -372,7 +372,7 @@ gst_my_filter_sink_event (GstPad *pad, GstObject * parent, GstEvent * event)
|
|||
The flush-stop event is created with
|
||||
<function>gst_event_new_flush_stop ()</function>. It has one
|
||||
parameter that controls if the running-time of the pipeline should
|
||||
be reset to 0 or not. Normally aftera flushing seek, the
|
||||
be reset to 0 or not. Normally after a flushing seek, the
|
||||
running_time is set back to 0.
|
||||
</para>
|
||||
</sect2>
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
<title>Quality Of Service (QoS)</title>
|
||||
|
||||
<para>
|
||||
Quality of Service in &GStreamer; is about measuring and ajusting
|
||||
Quality of Service in &GStreamer; is about measuring and adjusting
|
||||
the real-time performance of a pipeline. The real-time performance is
|
||||
always measured relative to the pipeline clock and typically happens in
|
||||
the sinks when they synchronize buffers against the clock.
|
||||
|
@ -82,7 +82,7 @@
|
|||
</para>
|
||||
<para>
|
||||
A synchronizing element also needs to measure its own performance in
|
||||
order to figure out if the performace problem is upstream of itself.
|
||||
order to figure out if the performance problem is upstream of itself.
|
||||
</para>
|
||||
<para>
|
||||
These measurements are used to construct a QOS event that is sent
|
||||
|
@ -184,7 +184,7 @@
|
|||
<para>
|
||||
Long term corrections are a bit more difficult to perform. They
|
||||
rely on the value of the proportion in the QOS event. Elements should
|
||||
reduce the amount of resources they comsume by the proportion
|
||||
reduce the amount of resources they consume by the proportion
|
||||
field in the QoS message.
|
||||
</para>
|
||||
<para>
|
||||
|
|
|
@ -109,7 +109,7 @@ gst_my_filter_class_init (GstMyFilterClass *klass)
|
|||
TagSetter interface (which is just a layer). Pipeline tags are tags
|
||||
provided to the element from within the pipeline. The element receives
|
||||
such tags via the <symbol>GST_EVENT_TAG</symbol> event, which means
|
||||
that tags writers should implment an event handler. The tag writer is
|
||||
that tags writers should implement an event handler. The tag writer is
|
||||
responsible for combining all these three into one list and writing them
|
||||
to the output stream.
|
||||
</para>
|
||||
|
|
Loading…
Reference in a new issue