decrease the refcount.
Each thread having a refcount to the object can safely read from the object.
- but modifications made to the object should be preceeded with a
+ but modifications made to the object should be preceded with a
_get_writable() function call. This function will check the refcount of the
object and if the object is referenced by more than one instance, a copy is
made of the object that is then by definition only referenced from the calling
Transform elements transform input buffers to output buffers based
on the sink and source caps.
-An important requirement for a transform is that the ouput caps are completely
+An important requirement for a transform is that the output caps are completely
defined by the input caps and vice versa. This means that a typical decoder
element can NOT be implemented with a transform element, this is because the
-output caps like width and height of the decompessed video frame, for example,
-are endcoded in the stream and thus not defined by the input caps.
+output caps like width and height of the decompressed video frame, for example,
+are encoded in the stream and thus not defined by the input caps.
Typical transform elements include:
- audio convertors (audioconvert, audioresample,...)
- video convertors (colorspace, videoscale, ...)
- - filters (capfilter, volume, colorbalance, ...)
+ - filters (capsfilter, volume, colorbalance, ...)
The implementation of the transform element has to take care of
the following things:
- get_unit_size()
- When the input size and output size are always a multiple of eachother
+ When the input size and output size are always a multiple of each other
(audio conversion, ..) we can define a more simple get_unit_size() function.
The transform will use this function to get the same amount of units in the
source and destination buffers.
EOS
~~~
-The EOS event can only be sent on a sinkpad. It is typically emited by the
+The EOS event can only be sent on a sinkpad. It is typically emitted by the
source element when it has finished sending data. This event is mainly sent
in the streaming thread but can also be sent from the application thread.
pipeline using the SEGMENT event.
Before sending buffers, an element must send a SEGMENT event. An element is
-free to refuse buffers if they were not preceeded by a SEGMENT event.
+free to refuse buffers if they were not preceded by a SEGMENT event.
Elements that sync to the clock should store the SEGMENT start and end values
and subtract the start value from the buffer timestamp before comparing
consumed the amount of time.
- sink posts STEP_DONE with amount of frames stepped and corresponding time
interval. The sink will then wait for another step event. Since the
- STEP_DONE message was emited by the sink when it handed off the buffer to
+ STEP_DONE message was emitted by the sink when it handed off the buffer to
the device, there is usually sufficient time to queue a new STEP event so
that one can seamlessly continue stepping.
"intermediate", G_TYPE_BOOLEAN
If this is an intermediate step operation that queued/activated.
-The STEP_START message is emited 2 times:
+The STEP_START message is emitted 2 times:
* first when an element received the STEP event and queued it. The "active"
field will be FALSE in this case.
* second when the step operation started in the streaming thread. The "active"
- field is TRUE in this case. After this message is emited, the application
+ field is TRUE in this case. After this message is emitted, the application
can queue a new step operation.
The purpose of this message is to find out how many elements participate in the
"eos", G_TYPE_BOOLEAN
The step ended because of EOS.
-The message is emited by the element that performs the step operation. The
+The message is emitted by the element that performs the step operation. The
purpose is to return the duration in GST_FORMAT_TIME of the stepped media. This
especially interesting to align other stream in case of stepping frames on the
video sink element.
GST_MESSAGE_BUFFERING:
An element is buffering data and that could potentially take some time. This
- message is typically emited by elements that perform some sort of network
+ message is typically emitted by elements that perform some sort of network
buffering. While the pipeline is buffering it should remain in the PAUSED
state. When the buffering is finished, it can resume PLAYING.
To do this, the source pads of the decoders is blocked so that no
events or buffers can escape and we don't interrupt the stream.
-When all of the dynamic pad are created (no-more-pads emited by the
+When all of the dynamic pad are created (no-more-pads emitted by the
branching point, ie, the demuxer or the queues filled) and the pads
are blocked (blocked callback received) the pipeline is completely
prerolled.
call _set_parent() on the children with the same parent, the parent
can then add all those to its lists.
- Note: that the signal is emited before the parent has added the
+ Note: that the signal is emitted before the parent has added the
element to its internal data structures. This is not a problem
since the parent usually has his own signal to inform the app that
the child was reffed. One possible solution would be to update the
- properties
- - two objects have references to eachother
+ - two objects have references to each other
- both objects can only have 1 reference to another object.
- reference fields protected with LOCK
- the references held by each object are NOT reflected in the
- properties
- - two objects have references to eachother
+ - two objects have references to each other
- reference fields protected with LOCK
- the references held by each object are reflected in the
refcount of the other object.
projects / platform / upstream / gstreamer.git / commitdiff