mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-23 00:36:51 +00:00
docs: fix common typos emited/eachother/...
This commit is contained in:
parent
7e5dc030f5
commit
a3431f5d8b
7 changed files with 17 additions and 17 deletions
|
@ -41,7 +41,7 @@ Shared data structures and writability:
|
|||
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
|
||||
|
|
|
@ -4,17 +4,17 @@ Transform elements
|
|||
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:
|
||||
|
@ -299,7 +299,7 @@ retrieve the size. There are two functions:
|
|||
|
||||
- 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.
|
||||
|
|
|
@ -104,7 +104,7 @@ elements so that the running_time is reset to 0.
|
|||
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.
|
||||
|
||||
|
@ -153,7 +153,7 @@ point for all next buffer's timestamps has to be propagated through the
|
|||
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
|
||||
|
|
|
@ -86,7 +86,7 @@ Use Cases
|
|||
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.
|
||||
|
||||
|
@ -190,13 +190,13 @@ A GST_MESSAGE_STEP_START is created. It contains the following fields.
|
|||
"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
|
||||
|
@ -227,7 +227,7 @@ fields:
|
|||
"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.
|
||||
|
|
|
@ -46,7 +46,7 @@ GST_MESSAGE_TAG:
|
|||
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.
|
||||
|
||||
|
|
|
@ -309,7 +309,7 @@ any data.
|
|||
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.
|
||||
|
|
|
@ -113,7 +113,7 @@ parent-child relation
|
|||
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
|
||||
|
@ -350,7 +350,7 @@ unreffed relation
|
|||
|
||||
- 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
|
||||
|
@ -475,7 +475,7 @@ double-reffed relation
|
|||
|
||||
- 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.
|
||||
|
|
Loading…
Reference in a new issue