dnl Overview:
dnl GST_OPTION_CFLAGS: common cflags for profiling, debugging, errors, ...
dnl GST_ALL_*: vars shared by all built objects
-dnl GST_LIB_LDFLAGS: additional linker flags for all libaries
+dnl GST_LIB_LDFLAGS: additional linker flags for all libraries
dnl GST_OBJ_*: additional vars to link to the core library
dnl include GST_ALL_*
dnl GST_LT_LDFLAGS: library versioning of our libraries
</para>
<chapter id="gstreamer-base">
- <title>GStreamer Base and Utillity Classes</title>
+ <title>GStreamer Base and Utility Classes</title>
<para>
libgstbase-&GST_API_VERSION;.so provides some base classes to be extended
- by elements and utillity classes that are most useful for plugin developers.
+ by elements and utility classes that are most useful for plugin developers.
</para>
<xi:include href="xml/gstaggregator.xml" />
short term core API stability
-----------------------------
-Changes that probably impact the API, carefull discussion (IRC) + design doc is required
+Changes that probably impact the API, careful discussion (IRC) + design doc is required
before changes are accepted.
target release ! description
!
0.4.1 ! expose and API to query the supported seek formats/flags on
- (done) ! pads, somthing like an extra arg to gst_pad_set_convert_function
+ (done) ! pads, something like an extra arg to gst_pad_set_convert_function
! and gst_pad_set_event_function with some function to query the
! flags and formats. more ideas in docs/random/wtay/query_events
- ! (API: medium dificulty)
+ ! (API: medium difficulty)
!
0.4.1 ! add event for segment playback/looping and seeking (docs/random/wtay/segments)
- (done) ! (API: medium dificulty, plugins: HARD to very HARD)
+ (done) ! (API: medium difficulty, plugins: HARD to very HARD)
!
? ! add event to adjust rate (reverse playback, slow motion, frame skipping)
! (docs/random/wtay/rate_event)
- ! (API: medium dificulty, plugins: HARD to very HARD)
+ ! (API: medium difficulty, plugins: HARD to very HARD)
!
? ! add method in the scheduler to set the entry point (frame stepping?)
! (docs/random/wtay/scheduler_entry)
the same procedure happens for the audio part. We are now left with the
following pipeline:
- We will also have set a signal "new_pad" on the mpeg1parse element bacause
+ We will also have set a signal "new_pad" on the mpeg1parse element because
the element mp1videoparse could not be connected to the element just yet.
(------------------------------------) (----------
---------
this is obviously a very naive solution. the creation of the elements actually happens
-beforehand. MPEG2, for one, fails bacause there are multiple possibilities to go
+beforehand. MPEG2, for one, fails because there are multiple possibilities to go
from the mpeg demuxer to audio/raw (ac3, mp3)
Also any intermedia elements like mixers (subtitles) are not possible because we
(HACK) we always use a new thread for the elements when there is a common
element found.
-if a new thread is needed (either becuase the previous element is a common
+if a new thread is needed (either because the previous element is a common
element or the object flag of the next element is set to GST_SUGGEST_THREAD)
we add a queue to the bin and we add a new thread. We add the elements to
the bin and connect them using gst_pipeline_pads_autoplug.
element itself. Note that there is a slight bit of duplication in the
playbin interface and the switch-like element interface, but that's "just
the way it is".
-The implemention of the switch-like element could initially be local to
+The implementation of the switch-like element could initially be local to
playbin, until it has been cleaned up and confirmed to be useful to a
wider audience. This allows a lot of experimenting with interfaces because
we won't be forced to maintain a stable interface.
We call this the static case because the capabilities of the pads
are supposed to stay the same after creating the element.
-While the ability to completly setup the pipeline before actually
+While the ability to completely setup the pipeline before actually
starting playback is an advantage regarding performance, one obvious
problem with this setup is that the static case may be too static in
some cases. We can illustrate this with the following setup:
NULL
};
-The static autoplugger has to be carefull when connecting the mpg123
+The static autoplugger has to be careful when connecting the mpg123
element with the audiosink because it is theoretically possible that
the mpg123 element outputs raw audio with a rate that cannot be
handled by the audiosink (ex. 4000KHz). In the absence of another
gst_pad_add_type_id(mpg123->sinkpad, mp3type);
The idea would then be that a rough draft of the pipeline would be
-built afer the media type of the stream has been detected with the
+built after the media type of the stream has been detected with the
typefind functions. The rough draft would consist of laying out a
global plan to reach the renderer(s). this plan would basically list
the set of conversions that have to be performed. (mime-type to
If the element accepts the buffer, it will set its capabilities for
both the sink pad and the src pad. At that time other elements can be
tried and added to the src pad, until we reach the renderer. As usual
-one has to be carefull to add just the minimum amount of elements to
+one has to be careful to add just the minimum amount of elements to
reach the renderer. The global plan will help with that.
Since we basically do not use the capabilities of the sink pad one has
in any potential situation. Simultaneously, these caps should be
as specific as possible, since it is used to decide which elements
to attempt for autoplugging, without having to load the element.
-The pad template caps are generally detemined at compile time, but
+The pad template caps are generally determined at compile time, but
might be actually computed at run-time from other information.
The getcaps() function returns the caps supported by a given pad,
a clock to other elements. These elements have to update the clock, when it is
used. When a clock is used (state != NULL - FIXME: or other states?), the
provider is guaranteed to use this clock. (FIXME: necessary?). The element is
-however required to synchronize to the clock it was assigned to, wether it is
+however required to synchronize to the clock it was assigned to, whether it is
its own clock or not.
SYNC POINTS
GstElementState gst_clock_get_state (GstClock *clock); /* setting works internally */
GstClockReturn gst_clock_wait (GstClock *clock, GstClockTime until, GstClockTimeDiff *jitter);
-GST_FLAG GST_ELEMENT_NEEDS_CLOCK; /* wether we want a clock or not */
+GST_FLAG GST_ELEMENT_NEEDS_CLOCK; /* whether we want a clock or not */
GstClockTime gst_element_get_time (GstElement *element);
void gst_element_(clock_)seek (GstElement *element, GstClockTimeDiff diff);
GstClock * gst_element_get_clock (GstElement *element);
You can even enhance the class struct, if you want to. This works just like inheritance in GLib.
-If it can be a parent class, it should implement these three functions publically:
+If it can be a parent class, it should implement these three functions publicly:
void gst_my_data_init (GstMyData *data) {
/* call the parent's init function, eg: */
gst_data_init (GST_DATA (data));
Upstream events
===============
-These will be discussed in a seperate doc.
+These will be discussed in a separate doc.
to create the link to save you some typing work and that not specifying a pad
name will automatically create 1 connection between the two elements. If more
than one connection was possible you might end up surprised.
-You may even specify pad lists to connect elements. They are seperated by
+You may even specify pad lists to connect elements. They are separated by
commas.
example:#> gst-launch fakesrc ! tee name=tee1 .src0,src1 ! .sink0, sink1 aggregator ! fakesink
example:#> gst-launch fakesrc ! tee name=tee aggregator name=aggregator ! fakesink tee.src0,src1 ! aggregator.sink0, sink1
has been used outside the real of multimedia, for example in the gst-sci
package[8] that provides statistical data analysis.
-This paper focusses on the GStreamer core and explains the goals of the
+This paper focuses on the GStreamer core and explains the goals of the
framework and how the core tries to achieve these by following a simple
mp3 playback example.
To allow easy extensibility, the complete media processing functionality
inside GStreamer is provided via plugins. Upon initialization a plugin
-registeres its different capabilities with the GStreamer library. These
+registers its different capabilities with the GStreamer library. These
capabilities are schedulers, typefind functions or - most common - elements.
The capabilities of plugins are recorded inside the registry.
The registry
The registry is a cache file that is used to inspect certain plugin capabilities
-without the need to load the plugin. As an example those stored capabilites
+without the need to load the plugin. As an example those stored capabilities
enabled automatically determining which plugins must be loaded in order to
decode a certain media file.
The gst-register(1) command updates the registry file. The gst-inspect(1)
The last step in creating a pipeline is linking pads. When attempting to link
two pads, GStreamer checks that a link is possible and if so, links them. After
they are linked data may pass through this link. Most of the time (just like
-in this example) convenience funtions are used that automatically select the
+in this example) convenience functions are used that automatically select the
right elements to connect inside a GStreamer pipeline.
GST_STATE_NULL is the 'uninitialized' state. Since it is always possible to
create an element, nothing that might require interaction or can fail is done
while creating the element. During the state transition elements are supposed
-to initialize external ressources. A file source opens its file, X elements
+to initialize external resource. A file source opens its file, X elements
open connections to the X server etc. This ensures that all elements can
provide the best possible information about their capabilities during future
interactions. The GStreamer core essentially does nothing. After this
GST_STATE_READY to GST_STATE_PAUSED
During this state change all internal dependencies are resolved. The GStreamer
-core tries to resolve links between pads by negotiating capabilites of pads.
+core tries to resolve links between pads by negotiating capabilities of pads.
(See below for an explanation.) The schedulers will prepare the elements for
playback and the elements will prepare their internal data structures. After
this state change is successful, nearly all elements are done with their setup.
Quoting iain <iain@prettypeople.org>:
> If you could write a small thing about how to use the tagging, it'd be
-> appreciated. I think MArlin is going to be using it pretty extensivly,
+> appreciated. I think MArlin is going to be using it pretty extensively,
> and so it'd be nice to get it in there and tested quickly.
>
Ok. A short writeup.
Time in Gstreamer
When talking about time in streams (or "clocking"), people often confuse 3
-different things that need to be treated seperately. Older designs in GStreamer
+different things that need to be treated separately. Older designs in GStreamer
confused those and this made it difficult to design solutions for time
management.
- The concept of GstBuffer from 0.8 will be split into two types.
One type will focus solely on holding information pertaining to
ownership of a memory area (call this GstMemBuffer), and the
- other type will focus solely in transfering information between
+ other type will focus solely in transferring information between
elements (call this GstPipeBuffer). In case you get confused,
GstMemBuffers _are not_ transferred between elements, and
GstPipeBuffers _do not_ own the memory they point to.
This means that the element will create a new pas depending on the
media type it is handling. For example, the mpeg1pdemuxer element will
create one or more video pads and one or more audio pads depending
-on the number of elementtary streams found in the media stream.
+on the number of elementary streams found in the media stream.
The element will present its dynamic pads with the padtemplate list
attached to the elementfactory. both the MIME type, direction, presence
compressor element to this pad.
An element that can be requested for a new pad has to implement the
-gst_element_request_new_pad method and perform the nessesary steps
+gst_element_request_new_pad method and perform the necessary steps
to create a pad from that template.
This interesting behaviour can be extended to ghostpads too. A
At runtime when the proxy-element receives data it sends it to the remote
element and after processing it gets it back and forwards it to the element.
-The challenge is to optimize links when multiple conected elements are on the
+The challenge is to optimize links when multiple connected elements are on the
same remote machine so that the data gets passed directly there.
== proxy creation ==
* functions in gst-controller.c could try the key,
if no handler is registered the try the type_parent and so on
-* implement quadric/qubic interpolation
+* implement quadric/cubic interpolation
BufferPools
-----------
-This document proposes a mechnism to build pools of reusable buffers. The
+This document proposes a mechanism to build pools of reusable buffers. The
proposal should improve performance and help to implement zero-copy usecases.
Last edited: 2009-09-01 Stefan Kost
- hardware based elements like to reuse buffers as they e.g.
- mlock them (dsp)
- - establish a index<->adress relation (v4l2)
+ - establish a index<->address relation (v4l2)
- not reusing buffers has overhead and makes run time behaviour
non-deterministic:
- - malloc (which usualy becomes an mmap for bigger buffers and thus a
+ - malloc (which usually becomes an mmap for bigger buffers and thus a
syscall) and free (can trigger compression of freelists in the allocator)
- shm alloc/attach, detach/free (xvideo)
- some usecases cause memcpys
- not having the right amount of buffers (e.g. too few buffers in v4l2src)
- receiving buffers of wrong type (e.g. plain buffers in xvimagesink)
- - receving buffers with wrong alignment (dsp)
- - some usecases cause unneded cacheflushes when buffers are passed between
+ - receiving buffers with wrong alignment (dsp)
+ - some usecases cause unneeded cacheflushes when buffers are passed between
user and kernel-space
What is needed
--------------
-Elements that sink raw data buffers of usualy constant size would like to
+Elements that sink raw data buffers of usually constant size would like to
maintain a bufferpool. These could be sinks or encoders. We need mechanims to
select and dynamically update:
Proposal
--------
-Querying the bufferpool size and buffer alignments can work simillar to latency
+Querying the bufferpool size and buffer alignments can work similar to latency
queries (gst/gstbin.c:{gst_bin_query,bin_query_latency_fold}. Aggregation is
quite straight forward : number-of-buffers is summed up and for alignment we
gather the MAX value.
-Bins need to track which elemnts have been selected as bufferpools owners and
+Bins need to track which elements have been selected as bufferpools owners and
update if those are removed (FIXME: in which states?).
Bins would also need to track if elements that replied to the query are removed
for the negotiated format.
The bufferpool could be a helper GObject (like we use GstAdapter). If would
-manage a collection of GstBuffers. For each buffer t tracks wheter its in use or
+manage a collection of GstBuffers. For each buffer t tracks whether its in use or
available. The bufferpool in gst-plugin-good/sys/v4l2/gstv4l2bufferpool might be
a starting point.
the end to a specific alignment
- mlock: hardware that uses DMA needs buffers memory locked, if a buffer is
already memory locked, it can be used by other hardware based elements as is
- - cache flushes: hardware based elements usualy need to flush cpu caches when
+ - cache flushes: hardware based elements usually need to flush cpu caches when
sending results as the dma based memory writes do no update eventually
cached values on the cpu. now if there is no element next in the pipeline
that actually reads from this memory area we could avoid the flushes. All
Registry Change Hooks
----------------------
-This document proposes a mechnism to register on registry updates.
+This document proposes a mechanism to register on registry updates.
Last edited: 2009-11-09 Stefan Kost
= ideas =
== dynlinkpoint ==
* use cases
- * its ment to be used with one side disconnected to allow to connect elements
+ * its meant to be used with one side disconnected to allow to connect elements
at runtime
* it can be used in a pipeline to remove/insert elements at runtime
* element with 1 source- and 1 sinkpad
* when both connected it passes data thru
* if src is not connected it drops received buffers
-* if sink is not conected
+* if sink is not connected
* it does not push
* it creates silence on pull
* events
It basically thins out the index to save memory. Right now it only keeps index
entries marked with the avi keyframe flag.
-In gstreamer core we have some indexing objects. They are curently used nowhere.
-The idea is to use them and to make the index strategy plugable or configurable
+In gstreamer core we have some indexing objects. They are currently used nowhere.
+The idea is to use them and to make the index strategy pluggable or configurable
at run time.
The challenge is then to rewrite muxers and demuxers to use them instead of the
== ranking ==
Autopluggers like playbin and decodebin use the element caps plus static ranks
to create piplines.
-The rank of an elemnt right now refers to the quality/maturity of the element.
+The rank of an element right now refers to the quality/maturity of the element.
Elements with higher rank should be functionally more complete. If we have
multiple elements that are feature complete there is a draw.
-There are more decission criteria thinkable:
+There are more decision criteria thinkable:
* target processor (CPU,DSP,GPU)
-* ressource usage (CPU, memory)
+* resource usage (CPU, memory)
* license (proprietary, open source)
* quality (in terms of the audio/image quality)
* GST_TYPE_QUALITY_VS_SPEED
- get the name of a property that can be used to switch between
- a fast version for e.g. realtime usage
- - a slower version with higher precission that can be used for off-line
+ - a slower version with higher precision that can be used for off-line
rendering
* new interfaces for audio applications
* GST_TYPE_MULTI_VOICE
- fully evaluate caps?
GstCaps * gst_caps_copy_nth (const GstCaps *caps, guint nth);
-- eval stucture and copy
+- eval structure and copy
void gst_caps_truncate (GstCaps *caps);
- eval first structure as needed and remove GST_CAPS_FLAGS_LAZY + call free_func
rethink log format. current format:
* is not easy to parse/process by commandline tools
-* cannnot be easily diffed (timestamps, pid)
+* cannot be easily diffed (timestamps, pid)
gst_debug_log_default() is default gst-log handler.
try new via:
================================================================================
- daemon process
- - is a gstreamer appliation
+ - is a gstreamer application
- open physical sink, src elements
- prepends an adder to sinks
- appends an tee to sources
= qos profiling =
* what data is needed ?
- * (streamtime,propotion) pairs from sinks
+ * (streamtime,proportion) pairs from sinks
draw a graph with gnuplot or similar
* number of frames in total
* number of audio/video frames dropped from each element that support QOS
* add -r, --report option to gst-launch
* during playing we capture QOS-events to record 'streamtime,proportion' pairs
gst_pad_add_event_probe(video_sink->sink_pad,handler,data)
- * during playback we like to know when an elemnt drops frames
+ * during playback we like to know when an element drops frames
what about elements sending a qos_action message?
* after EOS, send qos-queries to each element in the pipeline
* qos-query will return:
* 1:1 elements are easy to handle
* 0:1 elements need a start timer
* 1:0 elements need a end timer
- * n:1, 1:m and n:m type elemnts are tricky
+ * n:1, 1:m and n:m type elements are tricky
adapter based elements might have a fluctuating usage in addition
// result data
The plugin asked to read on the underlying resource (using bytestream),
but failed. The user will get a generic read error. The debug info
will contain the exact position in the stream at which the read error
- occured.
+ occurred.
* vertical events
- Vertical events travel from elements to their parents. They are targetted at
+ Vertical events travel from elements to their parents. They are targeted at
the application. Vertical events should be used for information that an
application cannot receive in an easy way by using callbacks or properties.
Vertical events are send to the application by the pipeline that collects those
microseconds).
Props consist of key / value pairs, where the key is a string identifier and the value
is a GstPropEntry. Many key strings are predefined to allow consistency between elements.
-Elements should try to suppy any information they can as soon as possible.
+Elements should try to supply any information they can as soon as possible.
GST_EVENT_HAS_INFO
direction(s): upstream
a single reference. If it forwards the event, this reference is lost.
Events own a reference to the element that created them. They take care of all of all
data inside them too (strings, props). So elements and applications that want to keep
-this informations need to copy or add a reference them.
+this information need to copy or add a reference them.
Changing Events
---------
Following are some simple use cases describing how events are generated. The pipeline
-decriptions use gst-launch syntax. "..." indicates that something follows there but is
+descriptions use gst-launch syntax. "..." indicates that something follows there but is
not important for the example.
* filesrc ! fakesink
will not be forwarded by mad.
- When playing starts, mad is able to compute bitrate and other information including playing
time with the help of the previous length information supplied by the filesrc. It will then
- issue another INFO event with that informations. This one will be send downstream and vertical.
+ issue another INFO event with that information. This one will be send downstream and vertical.
* ... ! avimux ! filesink
files have a limited filesize. Only 4 GB are allowed. We now show what happens when the avimux
encoder hits that limit.
- When the internal counter of avimux shows that it is approaching the filesize limit, the
- avimux element pushes a buffer containig the footer to the filesink.
+ avimux element pushes a buffer containing the footer to the filesink.
- After that it issues a DISCONTINUOUS event of the type DISCONT_NEW indicating a new stream.
The filesink will close the file and reopen a new one.
- The avimux plugin resets its internal size counter and restarts sending data to the new file.
- The gunzip element has already decoded the whole data so it knows the size of the stream. It
calls the callback for "length_size" and forwards the event.
- The filesrc supplies the "URI" and the "length_size" for a second time. It is now up to the
- application's callback function to handle this second occurence of "length_size" information.
+ application's callback function to handle this second occurrence of "length_size" information.
The filesrc does not forward the event and dereferences it.
- During disposal of the event, the callback function is called again with name=NULL. The
application now knows that no "title" can be supplied.
GStreamer data protocol
Intended to wrap GstData objects in a line protocol for use with
pipe / network elements.
- IDEAS-- -- -*for transporting buffers, have a function that creates a header for a given buffer to be written before the buffer.This way, you don 't lose
- time creating a GDP buffer from the buffer
+ IDEAS-- -- -*for transporting buffers, have a function that creates a header for a given buffer to be written before the buffer.
+ This way, you don't lose time creating a GDP buffer from the buffer
* allow for CRC' ing of the GstBuffer, optionally * have a version number of the protocol * optimizing the header for size is not useful since the GstData structure
already contains more than 32 bytes anyway, making up half the header size PROTOCOL-- -- ----*1 byte GDP major
version (0)
These notes describe deadlock scenarios and proposed solutions for
GStreamer. This will be implemented in the INCSCHED1 branch.
-I. Miscelaneous proposals
-II. Liveness problems (sometimes deadlock ;) and propsed solutions
+I. Miscellaneous proposals
+II. Liveness problems (sometimes deadlock ;) and proposed solutions
III. State transition approach and responsibility
MattH.
circumstance, the getcaps function can be omitted.
- If you use gst_pad_use_explicit_caps(), the getcaps function must
- be ommitted.
+ be omitted.
- fixate functions are a method for applications to exert influence
on how a format is chosen from a caps. It's also used as a hack to
gstpad. Modified the videosink to implement the pull. This function
allows a source element to request a buffer from the destination.
This is much more efficient because the videosink can then pass a
- buffer with SHM to the element, which does not require an aditional
+ buffer with SHM to the element, which does not require an additional
memcpy. removed scaling from the videosink. I need something
better.
-things to remember for the anouncement:
+things to remember for the announcement:
---------------------------------------
Build requirements list:
};
A copy of the audiosink is instantiated and attached, negotiation goes smoothly, and we're done. No
-dataflow has occured, no failure found, etc. An ideal autoplug.
+dataflow has occurred, no failure found, etc. An ideal autoplug.
Now, a slightly more convoluted example:
Whoops. It seems that the sound card we've got in this machine (FIXME how on earth to deal with
multiple sound cards???) doesn't support mono output *at all*. This is a problem. We now find that we
-hae no options as far as directly matching the mpg123 to the audiosink.
+have no options as far as directly matching the mpg123 to the audiosink.
-A look through our (ficticious) plugin registry shows at least one element that at least has audio/raw
-on both input and ouput (since both mpg123 and audiosink have open pads with this mime type). A closerlook shows that its caps are:
+A look through our (fictitious) plugin registry shows at least one element that at least has audio/raw
+on both input and output (since both mpg123 and audiosink have open pads with this mime type). A closerlook shows that its caps are:
static GstCapsFactory mono2stereo_sink_caps = {
"audio/raw",
};
This seems to be a task for typefind again. But since data is flowing, we have to be careful with the
-buffers. (This is the case in any typefind maneuver, but moreso when one really can't rewind the
+buffers. (This is the case in any typefind maneuver, but more so when one really can't rewind the
source without consequences) The autoplug system attaches a special pseudo-element to mpeg2parse's new
output pad, and attaches the typefind element to the end of that. The pseudo-element takes the buffer,
stores it, and passes a copy off to the attached element, in this case typefind. This repeats until
that). By way of some logic in gst_bin_change_state(), gst_bin_create_plan() is only called for the
outer Bin, usually a Pipeline. This keeps things from getting nasty later on.
-A major new concept in plan generation is that of the 'manager'. This is the element that is reponsible
+A major new concept in plan generation is that of the 'manager'. This is the element that is responsible
for running a given element. In general, Pipelines and Threads are the only managing-capable elements
(have the MANAGER flag set), since they are the only ones with real scheduling authority (because they
have a process context to play with, basically).
For all MANAGER Bins, the last step is to actually create the scheduling plan. This is still one of the
nastiest chunks of code in the whole project, and probably will do nothing but get worse from now on (it
-got better recently, but only because I took a chainsaw to the code and broke everthing...). It will
+got better recently, but only because I took a chainsaw to the code and broke everything...). It will
remain similar to what it is now, but with some definite differences.
First task is now to find all the elements that we're responsible for. This is normally a recursive
loopfunc_wrapper: used for loop-based elements, it simply calls the
loopfunc in a loop, paying attention to COTHREAD_STOPPING (see
- below). It currently does other, soon to be depracated, stuff.
+ below). It currently does other, soon to be deprecated, stuff.
pullsrc_wrapper: wraps a Src that's not loop-based (since your options
are now loop- or pull-based)
the pad, there is at least one case where scheduling has to be tricked, by providing a pointer to a
function with no body.
-What I propse is that these functionos be replaced with macros that call a function pointer directly.
+What I propose is that these functions be replaced with macros that call a function pointer directly.
The default functions (provided by GstPad) would be capable of chaining, that's about it. When a
schedule is formed, these get replaced with more specific functions, provided by GstBin or a subclass.
2) Threading:
- - Can signals be emited from any thread?
+ - Can signals be emitted from any thread?
- what operations are permited from a signal handler?
3) Error reporting
- How does error reporting work?
* an audio/video device/port is busy.
- * a fatal decoding error occured.
+ * a fatal decoding error occurred.
* a media type is not supported
Phonon::VolumeFaderEffect
- Alows fade-in and fade-out with a configurable curve and time. Needs
+ Allows fade-in and fade-out with a configurable curve and time. Needs
GstController.
Phonon::BrightnessControl
- If called after starting ByteStream, the Phonon::ByteStream::seekStream
signal can be called for push-based seekable streams.
- * Can the signals be emited from a streaming thread?
+ * Can the signals be emitted from a streaming thread?
Phonon::AudioDataOutput/Phonon::VideoDataOutput/
Notes :
* Phonon::AudioDataOutput::dataReady
- - can this be emited from the streaming threads?
+ - can this be emitted from the streaming threads?
* Phonon::AudioDataOutput::endOfMedia
- - can this be emited from the streaming threads?
+ - can this be emitted from the streaming threads?
- We need to grab this EOS message synchronously from the bus.
- - should be emited _before_ sending the last dataReady. This means we need
+ - should be emitted _before_ sending the last dataReady. This means we need
to cache at least one dataReady.
* Phonon::AudioDataOutput::setDataSize
are possible somewhere downstream.
gst_pad_alloc_buffer() would take a GstBuffer as an input argument to make the
- API easier, we can then use metadata to specify additional contraints for the
+ API easier, we can then use metadata to specify additional constraints for the
new buffer (such as strides, etc)
an element factory has the following information:
- a unique name for the element factory
- - strings describing the element (name, desciption, copyright,...)
+ - strings describing the element (name, description, copyright,...)
- a description of the media types it accepts (as capabilities)
- a description of the media types it outputs (as capabilities)
Also segment accumulation was removed from the segment event. This means
that now the source/demuxer/parser needs to add the elapsed time of the
previous segment themselves (this must be added to segment->base). If this
- is not done, looped playback wont work.
+ is not done, looped playback won't work.
accum was renamed to base. last_stop was renamed to position.
// in the queue
// thread1 has put the last buffer on the queue
- // here. A signal is going to be emited
+ // here. A signal is going to be emitted
tosignal = (queue->level_buffers >= 0);
queue->level_buffers++;
Tbe implementation that I suggest contains an rtpdec element. This element has one sink pad for the data, one src pad for the decoded data, and a pair of src and sink pads for control messages. The decoded data that comes from rtpdec has no RTP dependency. It is in the format expected by the codec that it decodes it. Therefore, rtpdec must do codec specific processing of data to take into account that different codecs are stored differently in RTP.
-A posible pipeline is:
+A possible pipeline is:
udpcon name="data" udpcon name="control" data.src!rtpdec.datasrc control.src!rtpdec.controlin control.sink!rtpdec.controlout rtpdec name="rtpdec" ! mp3decode ! osssink
-udpcon is an element (not yet written) that provides a src and a sink pad to read and write to a socket. There are two udpcon, one for reading the data socket and another for reading and writting to the control socket.
+udpcon is an element (not yet written) that provides a src and a sink pad to read and write to a socket. There are two udpcon, one for reading the data socket and another for reading and writing to the control socket.
To handle variable types, the following would work (the UDP part left out for clarity is identical to the one above):
rtpdec has a property that tells it the mapping of the payload bits to mime type. This is necessary, because that mapping is not fixed. It has to be obtained at runtime through other mechanisms, such as a SDP file obtained by http or rtsp.
-A posible implementation of rtpdec is a bin that contains two elements: a media independent _rtpparse and a media dependent rtp-dec-mp3. Thus the pipeline would be
+A possible implementation of rtpdec is a bin that contains two elements: a media independent _rtpparse and a media dependent rtp-dec-mp3. Thus the pipeline would be
udpsrc ! _rtpparse ! rtp-dec-mp3 ! mp3decode ! osssink
\________________________/
rtpdec bin
-Another posible implementation is, that rtpdec opens a plugin that contains the code to convert the codec specific packets into the input that the normal decoder for that codec expects.
+Another possible implementation is, that rtpdec opens a plugin that contains the code to convert the codec specific packets into the input that the normal decoder for that codec expects.
Ronald said that this mechanism would be complicated because it would require to duplicate the functionality of the plugin loader. It shouldn't be like that because it should use the normal plugin loader. However, this is an issue that I do not fully understand.
Reuse of RTP logic would be achieved through inheritance.
-This looks more logical, because inheritance reflects the fact that rtp-mp3 "is an" specialization of rtp. However, there are several issues. As stated above, it is posible in RTP to switch the encoding of the media at any time. If this happens, some state must be kept, such as statistics of packets received and sent.
+This looks more logical, because inheritance reflects the fact that rtp-mp3 "is an" specialization of rtp. However, there are several issues. As stated above, it is possible in RTP to switch the encoding of the media at any time. If this happens, some state must be kept, such as statistics of packets received and sent.
- need possible porting to GNet (later)
- typefind:
- works
- - need tests - this definately could use it
+ - need tests - this definitely could use it
- is there any way they can be documented ?
- should the plugin docs show a list of them ?
- videorate:
- par conversion
- different scale algorithms
- needs docs
- - negotation with five out of six free variables (src/sink w/h/par)
+ - negotiation with five out of six free variables (src/sink w/h/par)
- videotestsrc:
- could use tests for all possible caps
- volume: OK
The second version is an "interface" version, used in versioning tools, the
library name, packages, GConf install paths, registry locations, and so on.
It is of the form x.y
-Commonly, it is refered to as the "major/minor" number of GStreamer.
+Commonly, it is referred to as the "major/minor" number of GStreamer.
In most cases it is the same as the one used in the source version; only
when we are doing release candidates for a new major/minor source version do
we manually force the major/minor to be the same as the one for the next
gst_type_new() (FIXME: badly named) function, which would first search for
that same MIME type in the current list. If it found one, it would
compare the two to see if the new one is "better". Better is defined as
-having more extentions (to be merged) or a typefind function verses none.
+having more extensions (to be merged) or a typefind function verses none.
The point of returning an existing MIME type is a result of the goal of
unifying types enough to guarantee that, for instance, all MP3 decoders
-will work interchangably. If MP3 decoder A says "MIME type 'audio/mpeg'
+will work interchangeably. If MP3 decoder A says "MIME type 'audio/mpeg'
with extensions 'mpeg3'" and decoder B says "MIME type 'audio/mpeg' with
extensions 'mp3'", we don't want to have two types defined, possibly with
two typefind functions. If we did, it's not obvious which of the two would
5. type hierarchy
-----------------
-some plugins can ouput a specific subset of an already existing type.
+some plugins can output a specific subset of an already existing type.
example:
example 2:
- suppose the typefind functions finds an mp3 stream, fillowing elments
+ suppose the typefind functions finds an mp3 stream, following elements
are selected:
libmpg123 mp3parse:
// a factory for the major type we use
static GstTypeFactory mp3factory = {
"audio/mp3", // major type
- ".mp3 .mp2 .mp1 .mpga", // extenstions
+ ".mp3 .mp2 .mp1 .mpga", // extensions
NULL, // typefind function
};
static GstTypeFactory mpegfactory = {
"video/mpeg", // major type
- ".mpg .mpeg", // extenstions
+ ".mpg .mpeg", // extensions
NULL, // typefind function
};
synchronised on music. MIDI players play them without any problem, ignoring the
additional data.
-It is the more widespread karaoke file format. (one other beeing .kok files, for mp3)
+It is the more widespread karaoke file format. (one other being .kok files, for mp3)
KAR files are based on standard MIDI files with the following additional events:
even on other machines over the network.
Wrapping the GStreamer objects in CORBA objects doesn't look
-like a problem. It will immediatly allow us to create objects
+like a problem. It will immediately allow us to create objects
accros the network and use the framework in a distributed
environment.
single stream.
I see bonobo as a high level service provider, you create a
-mediaplayer component that can be embeded into a document and
+mediaplayer component that can be embedded into a document and
stuff like that. The point here is that you use bonobo to
create services out of user apps build with GStreamer.
1) definition
-------------
-We want to define a plugable framework for autoplugging this
+We want to define a pluggable framework for autoplugging this
includes:
- autoplugging algorithms can be added and removed at run time.
The element can also return a NULL pointer if it has run out of
options for the caps structure. When this happens, both pads are set
-the NULL caps again and the pad connnection is broken.
+the NULL caps again and the pad connection is broken.
The negotiation process is stopped after a fixed number of tries,
when the counter has reached some limit. This limit is typically
function. osssink can try this list (or whatever remains of it) and whatever
works is sent back as the return value of the request_caps function.
- mad receives the caps list, takes the top caps and does a pad_set_caps
-- osssink recieves the final caps on its new_caps function and configures the
+- osssink receives the final caps on its new_caps function and configures the
oss driver.
and a value, which can be one of the following:
- an integer constant (ex. 5)
- - a float contant (ex. 1.0)
+ - a float constant (ex. 1.0)
- a string constant (ex. "int")
- a boolean constant (ex. FALSE)
- a fourcc constant (ex. I420)
that can be used for this connection.
For all not NULL intersections the pad connect functions are called with the
-intersection. Depending on the result of the connect funtion the connection is
+intersection. Depending on the result of the connect function the connection is
allowed or refused.
If the intersection is fixed and the pad connect functions agreed to the caps,
A Pad can be notified when another pad is connected or reconnected to it with
fixed or variable caps. This notification will be done with the optional
GstPadConnectFunction callback that an element can provide for a pad.
-Remember that this connection is _always_ called, not only whith fixed caps
+Remember that this connection is _always_ called, not only with fixed caps
but also with variable caps (if any).
We will explain some of the common situations with some examples.
A clock extends the abstract GstClock class.
gst_clock_get_time should always report an equal or increasing
-value with each succesive call.
+value with each successive call.
Sink elements.
else use a default System Clock.
-Src elements with a clock are prefered because they usualy provide
+Src elements with a clock are preferred because they usually provide
live audio/video.
Issues
the eos handler returns false because both queues return false on the
eos request. the parent removes fakesrc as an EOS provider.
- queue1 and queue2 were responisble for the EOS delay and so they get
+ queue1 and queue2 were responsible for the EOS delay and so they get
added to the bin as possible EOS providers.
after the queues have sent out their last buffer, they calls eos on their
src pads.
- the parent allready has the two queues in the EOS provider list so they dont
+ the parent already has the two queues in the EOS provider list so they dont
get added twice.
the two queues perform gst_pad_eos () on their pads when the queue is empty,
the parent removes the EOS providers from its list, when the list is empty,
the eos handler returns false because queue2 returns false on the
eos request. the parent removes fakesrc as an EOS provider.
- queue2 was responisble for the EOS delay and so it gets added to the bin
+ queue2 was responsible for the EOS delay and so it gets added to the bin
as a possible EOS provider.
after the queue2 has sent its last buffer, it performs gst_pad_eos on its
src pad.
- the parent allready has the queue2 in the list of EOS providers so it does not
+ the parent already has the queue2 in the list of EOS providers so it does not
get added twice.
queue2 finally fires the EOS signal and the parent removes the EOS provider
from its list, when the list is empty, the parent fires EOS.
as close to the buffers are possible.
- plugins should check the type of the GstData passed in the _chain
- or _loop function and act appropriatly. This can be done by either
+ or _loop function and act appropriately. This can be done by either
doing their own stuff or by calling the default handler.
- are handled on the sink pad.
application generated events
----------------------------
-The application can insert events into the pipeline at arbirary
+The application can insert events into the pipeline at arbitrary
places. This will be done by calling gst_pad_event() on a pad.
A first implementation will only cover inserting events on src pads
as close to the buffers are possible.
- plugins should check the type of the GstData passed in the _chain
- or _loop function and act appropriatly. This can be done by either
+ or _loop function and act appropriately. This can be done by either
doing their own stuff or by calling the default handler.
- are handled on the sink pad.
application generated events
----------------------------
-The application can insert events into the pipeline at arbirary
+The application can insert events into the pipeline at arbitrary
places. This is done by calling gst_pad_send_event() on a pad.
An application can also insert events on any element. The element
Requirements
------------
-- capture mouse clicks, mouse position, movement occuring on
+- capture mouse clicks, mouse position, movement occurring on
a video display plugin
- transport these events to the interested plugins
- allow for automation (ie, the technique should work without
do we need a library for this?
do we use custom events and use the mime type to detect the
-type? do we creat a GST_EVENT_NAVIGATION?
+type? do we create a GST_EVENT_NAVIGATION?
can we encapsulate all events into a GstCaps? I would think so
Consider the mp3parse element that could detect id3 tags in the stream.
One way to let the app know about those tags is by emitting a signal. The
problem with this signal is that the app has to perform a g_signal_connect
-on this element. This might not always be possible/feasable because
+on this element. This might not always be possible/feasible because
the APP might not know about the mp3parse element (eg. an autoplugged
pipeline or a compound object). The app could instrospect each element
in the pipeline and look for known properties/signals to connect to,
but that looks a bit ugly IMO.
-Signal proxying is also not very feasable because signals are tied to
+Signal proxying is also not very feasible because signals are tied to
class instances.
let's take the following use case:
Requirements
------------
-The application can listen to an abritrary bin in the pipeline to collect
+The application can listen to an arbitrary bin in the pipeline to collect
information about that bins children. The app can listen on the top
level bin to collect all of the elements messages.
We can see obvious problems when a user app (unaware of the
core tags) is also trying to use the 'element' tag for its
own purposes. The core might try to load the 'element' tag
-desscribing the user app data and the user app might get fed
+describing the user app data and the user app might get fed
with XML data of the GStreamer core.
In this document we try to describe how we will solve this problem
</element>
</GST-Pipeline>
-Tha same document with namespaces look like this:
+The same document with namespaces look like this:
<?xml version="1.0"?>
<gst:GST-Pipeline xmlns:gst="http://gstreamer.net/gst-core/1.0/">
element that describes the position and size of the element as it was
laid out in the editor.
-For the examples sake, the tags that are used to descibe this meta data
+For the examples sake, the tags that are used to describe this meta data
will also be names 'element' in order to demonstrate the namespaces.
The editor will use its own namespace, being:
gst_object_save_thyself (GstObject *object, xmlNodePtr parent)
-Wich will call the elements implementation of the save_thyself function.
+Which will call the elements implementation of the save_thyself function.
An app that wants to insert its XML tags has to connect to a signal of
the GstObject object called xml_saved. The object and the parent
One obvious solution would be to attach a class signal to the
GstObject class that would be fired whenever an object is created from
-an XML document. Unfortunatly Gtk+ (or glib2.0) doesn't have class
+an XML document. Unfortunately Gtk+ (or glib2.0) doesn't have class
signals so we need something else. Another problem with the class
signals would be that the user app would also be notified of object
creation outside its context. For example, if two threads perform an
gst_pad_iterate_caps returns caps in the following order:
- 1) prefered caps (if any)
+ 1) preferred caps (if any)
2) negotiated caps (if any)
3) profile caps (if any, filtered against caps of current media type)
4) padtemplate caps (filtered against caps of current media type)
Required functionality
- get notification of data passing on arbitrary pad
- - posibility to drop data
- - posibility to change/inspect data
+ - possibility to drop data
+ - possibility to change/inspect data
- single shot probe
- filter on events/buffers?
- filter on timestamp?
always get the number of bytes from track0->track2.
If we want to get the number of bytes of one particular track, we have
-to substract two convert values. Look at the folowing figure to understand
+to substract two convert values. Look at the following figure to understand
this. The --- defines the region we want to convert.
- stuff like length an position depend on the pads of the element, you cannot
sanely expose a property for each pad to describe this.
- element properties can only report stuff with one type. If your property
- exposes somthing like "total_length", you cannot make it both report this
+ exposes something like "total_length", you cannot make it both report this
in time/bytes/samples/frames...
- impossible to sanely implement convert with element properties.
* You can fix this by:
- - inserting gst_element_yield () in sane places, don't exagerate because
+ - inserting gst_element_yield () in sane places, don't exaggerate because
every yield can potentially never return so you need to keep track of
allocations (see the NOTES below).
and free it in the state change function.
-IMPLEMENATION DETAILS
-=====================
+IMPLEMENTATION DETAILS
+======================
The infinite loops are only problematic if the scheduler chooses to select
the plugin as an entry point in the chain. _yield() will be a nop if this is
might have happened, killing off execution of the plugin. pulling/pushing buffers
will cause no leaks in this case because the core will free pending buffers in a
state change to READY. The plugin must free allocated data/buffers itself in the state
-change function if the yield didn't retrun.
+change function if the yield didn't return.
Requirements
------------
-- plugable backends:
+- pluggable backends:
- XML
- flat file
* a group has at most one loop based element
* elements in a group are sorted, src elements first (not mandatory)
* a group has one cothread
- * a group is created immediatly for loop based elements, all other elements
+ * a group is created immediately for loop based elements, all other elements
are added to a group when a pad connection is made
* get-based plugins are put in the same group as a peer loop based element
* chain based elements are put in the same group as sink peer elements
- negotiation is not designed to work over multithread boundaries.
negotiation over a queue is not possible. There is no method or policy of
- discovering a media type and then commiting it. It is also not possible to
+ discovering a media type and then committing it. It is also not possible to
tie the negotiated media to the relevant buffer.
ex1:
+---------+ +-----------------------+
This requirement is important when we need to sort the elements in the
- bin to perfrom the state change.
+ bin to perform the state change.
testcases:
GST_STATE_FAILURE is returned when the element failed to go to the
required state. When dealing with a bin, this is returned when one
of the elements failed to go to the required state. The other elements
- in the bin might have changed their states succesfully. This return
+ in the bin might have changed their states successfully. This return
value means that the element did _not_ change state, for bins this
means that not all children have changed their state.
This function will block while the state change function is running inside
the element because it grabs the element lock.
When the element did not perform an async state change, this function returns
- TRUE immediatly with the state updated to reflect the current state of the
+ TRUE immediately with the state updated to reflect the current state of the
element and pending set to None.
When the element performed an async state change, this function will block
for the value of timeout and will return TRUE if the element completed the
the elements. To make this easier we require that elements are connected to
bins using ghostpads on the bin.
- The algoritm goes like this:
+ The algorithm goes like this:
d = [ ] # list of delayed elements
p = [ ] # list of pending async elements
reply and will only commit the state change after receiving the first
buffer. This will implement the preroll phase.
- The following pseudo code shows an algorithm for commiting the state
+ The following pseudo code shows an algorithm for committing the state
change in the streaming method.
GST_OBJECT_LOCK (element);
Data transport was successful
GST_ERROR
- An error occured during transport, such as a fatal decoding error,
+ An error occurred during transport, such as a fatal decoding error,
the pad should not be used again.
GST_NOT_CONNECTED
pipeline when an error occurs.
Whenever an element posts a message on the event queue, a signal is also
- fired that can be catched by the application. When dealing with those
+ fired that can be caught by the application. When dealing with those
signals the application has to be aware that they come from the streaming
threads and need to make sure they use proper locking to protect their
own data structures.
----
- review
-- figure all state change scenarios occuring in code marked with (*)
+- figure all state change scenarios occurring in code marked with (*)
The purpose of GstTimecache is to provide an infrastructure for
plugins to maintain such an index.
-By creating a generic interace to this functionality, it is also
+By creating a generic interface to this functionality, it is also
possible for the application to make use of the generated index.
possible use cases are: saving/loading of indexes, obtain an
overview of the indexed stream (where is sample N, where is
/*
* this bit handles:
- * - initalization of threads if we use them
+ * - initialization of threads if we use them
* - log handler
* - initial output
* - initializes gst_format
do_state:
GST_OBJECT_LOCK (bin);
/* the element was busy with an upwards async state change, we must wait for
- * an ASYNC_DONE message before we attemp to change the state. */
+ * an ASYNC_DONE message before we attempt to change the state. */
if ((found =
find_message (bin, GST_OBJECT_CAST (element),
GST_MESSAGE_ASYNC_START))) {
/* check if all elements managed to commit their state already */
if (!find_message (bin, NULL, GST_MESSAGE_ASYNC_START)) {
/* nothing found, remove all old ASYNC_DONE messages. This can happen when
- * all the elements commited their state while we were doing the state
+ * all the elements committed their state while we were doing the state
* change. We will still return ASYNC for consistency but we commit the
* state already so that a _get_state() will return immediately. */
bin_remove_messages (bin, NULL, GST_MESSAGE_ASYNC_DONE);
- GST_DEBUG_OBJECT (bin, "async elements commited");
+ GST_DEBUG_OBJECT (bin, "async elements committed");
bin_handle_async_done (bin, GST_STATE_CHANGE_SUCCESS, FALSE,
GST_CLOCK_TIME_NONE);
}
GST_OBJECT_LOCK (bin);
/* If all sinks are EOS, we're in PLAYING and no state change is pending
- * (or we're doing playing to playing and noone else will trigger posting
+ * (or we're doing playing to playing and no one else will trigger posting
* EOS for us) we forward the EOS message to the parent bin or application
*/
eos = GST_STATE (bin) == GST_STATE_PLAYING
/* nothing found, remove all old ASYNC_DONE messages */
bin_remove_messages (bin, NULL, GST_MESSAGE_ASYNC_DONE);
- GST_DEBUG_OBJECT (bin, "async elements commited");
+ GST_DEBUG_OBJECT (bin, "async elements committed");
/* when we get an async done message when a state change was busy, we
* need to set the pending_done flag so that at the end of the state
* change we can see if we need to verify pending async elements, hence
}
/* If features is empty it will contain sysmem, however
- * we want to add it explicitely if it is tried to be
+ * we want to add it explicitly if it is attempted to be
* added as first features
*/
if (features->array->len > 0
/* GStreamer
* Copyright (C) 2007 Stefan Kost <ensonic@users.sf.net>
*
- * gstdebugutils.c: debugging and analysis utillities
+ * gstdebugutils.c: debugging and analysis utilities
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
/* TODO:
* edge [ constraint=false ];
* this creates strange graphs ("minlen=0" is better)
- * try puting src/sink ghostpads for each bin into invisible clusters
+ * try putting src/sink ghostpads for each bin into invisible clusters
*
* for more compact nodes, try
* - changing node-shape from box into record
/* GStreamer
* Copyright (C) 2007 Stefan Kost <ensonic@users.sf.net>
*
- * gstdebugutils.h: debugging and analysis utillities
+ * gstdebugutils.h: debugging and analysis utilities
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Library General Public
/**
* GstDevice:
- * @parent: The parent #GstObject strucuture.
+ * @parent: The parent #GstObject structure.
*
* A device object.
*
/**
* GstDeviceClass:
- * @parent_class: The parent #GstObjectClass strucuture.
+ * @parent_class: The parent #GstObjectClass structure.
* @create_element: Creates the fully configured element to access this device.
* Subclasses need to override this and return a new element.
* @reconfigure_element: This only needs to be implemented by subclasses if the
* @see_also: #GstDevice, #GstDeviceMonitor
*
* A #GstDeviceProvider subclass is provided by a plugin that handles devices
- * if there is a way to programatically list connected devices. It can also
+ * if there is a way to programmatically list connected devices. It can also
* optionally provide updates to the list of connected devices.
*
* Each #GstDeviceProvider subclass is a singleton, a plugin should
}
/* get a random pad on element of the given direction.
- * The pad is random in a sense that it is the first pad that is (optionaly) linked.
+ * The pad is random in a sense that it is the first pad that is (optionally) linked.
*/
static GstPad *
gst_element_get_random_pad (GstElement * element,
case GST_STATE_CHANGE_SUCCESS:
GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element,
"element changed state SUCCESS");
- /* we can commit the state now which will proceeed to
+ /* we can commit the state now which will proceed to
* the next state */
ret = gst_element_continue_state (element, ret);
break;
case GST_STATE_CHANGE_NO_PREROLL:
GST_CAT_DEBUG_OBJECT (GST_CAT_STATES, element,
"element changed state NO_PREROLL");
- /* we can commit the state now which will proceeed to
+ /* we can commit the state now which will proceed to
* the next state */
ret = gst_element_continue_state (element, ret);
break;
G_BEGIN_DECLS
-/* gstelement.h and gstelementfactory.h include eachother */
+/* gstelement.h and gstelementfactory.h include each other */
typedef struct _GstElement GstElement;
typedef struct _GstElementClass GstElementClass;
/**
* gst_event_parse_stream:
* @event: a stream-start event
- * @stream: (out) (transfer full): adress of variable to store the stream
+ * @stream: (out) (transfer full): address of variable to store the stream
*
* Parse a stream-start @event and extract the #GstStream from it.
*
* GST_FUNCTION:
*
* This macro should evaluate to the name of the current function and be should
- * be defined when configuring your project, as it is compiler dependant. If it
+ * be defined when configuring your project, as it is compiler dependent. If it
* is not defined, some default value is used. It is used to provide debugging
* output with the function name of the message.
*
}
error:
{
- /* something went wrong, restore the orginal state again
+ /* something went wrong, restore the original state again
* it is up to the subclass to log an error if needed. */
GST_CAT_INFO (GST_CAT_MEMORY, "mem %p: subclass map failed", mem);
gst_memory_unlock (mem, (GstLockFlags) flags);
#define GST_MESSAGE(obj) (GST_MESSAGE_CAST(obj))
/* the lock is used to handle the synchronous handling of messages,
- * the emiting thread is block until the handling thread processed
+ * the emitting thread is blocked until the handling thread processed
* the message using this mutex/cond pair */
#define GST_MESSAGE_GET_LOCK(message) (&GST_MESSAGE_CAST(message)->lock)
#define GST_MESSAGE_LOCK(message) g_mutex_lock(GST_MESSAGE_GET_LOCK(message))
g_return_val_if_fail (mini_object != NULL, NULL);
/* we can't assert that the refcount > 0 since the _free functions
- * increments the refcount from 0 to 1 again to allow resurecting
+ * increments the refcount from 0 to 1 again to allow resurrecting
* the object
g_return_val_if_fail (mini_object->refcount > 0, NULL);
*/
*
* Obtain the control-rate for this @object. Audio processing #GstElement
* objects will use this rate to sub-divide their processing loop and call
- * gst_object_sync_values() inbetween. The length of the processing segment
+ * gst_object_sync_values() in between. The length of the processing segment
* should be up to @control-rate nanoseconds.
*
* If the @object is not under property control, this will return
*
* Change the control-rate for this @object. Audio processing #GstElement
* objects will use this rate to sub-divide their processing loop and call
- * gst_object_sync_values() inbetween. The length of the processing segment
+ * gst_object_sync_values() in between. The length of the processing segment
* should be up to @control-rate nanoseconds.
*
* The control-rate should not change if the element is in %GST_STATE_PAUSED or
if (G_UNLIKELY (ev->event == NULL))
goto next;
- /* take aditional ref, func might release the lock */
+ /* take additional ref, func might release the lock */
ev_ret.event = gst_event_ref (ev->event);
ev_ret.received = ev->received;
GST_CAT_LOG_OBJECT (GST_CAT_SCHEDULING, pad, "adding probe for mask 0x%08x",
mask);
- /* when no contraints are given for the types, assume all types are
+ /* when no constraints are given for the types, assume all types are
* acceptable */
if ((mask & _PAD_PROBE_TYPE_ALL_BOTH_AND_FLUSH) == 0)
mask |= GST_PAD_PROBE_TYPE_ALL_BOTH;
/* add the probe */
g_hook_append (&pad->probes, hook);
pad->num_probes++;
- /* incremenent cookie so that the new hook get's called */
+ /* incremenent cookie so that the new hook gets called */
pad->priv->probe_list_cookie++;
/* get the id of the hook, we return this and it can be used to remove the
* 2) application and 3) user order. Whenever an earlier entry is newer, the
* later entries will be updated. Since 1.8 you can also provide extra paths
* where to find presets through the GST_PRESET_PATH environment variable.
- * Presets found in those paths will be concidered as "app presets".
+ * Presets found in those paths will be considered as "app presets".
*/
/* FIXME:
* - non racyness
gchar padder[ALIGNMENT] = { 0, };
int padsize = 0;
- /* Padding to insert the struct that requiere word alignment */
+ /* Padding to insert the struct that require word alignment */
if ((chunk->align) && (alignment (*file_position) != 0)) {
padsize = ALIGNMENT - alignment (*file_position);
if (gst_registry_binary_cache_write (cache, *file_position,
GstElementFactory *factory = GST_ELEMENT_FACTORY (feature);
/* Initialize with zeroes because of struct padding and
- * valgrind complaining about copying unitialized memory
+ * valgrind complaining about copying uninitialized memory
*/
ef = g_slice_new0 (GstRegistryChunkElementFactory);
pf_size = sizeof (GstRegistryChunkElementFactory);
gchar *str;
/* Initialize with zeroes because of struct padding and
- * valgrind complaining about copying unitialized memory
+ * valgrind complaining about copying uninitialized memory
*/
tff = g_slice_new0 (GstRegistryChunkTypeFindFactory);
pf_size = sizeof (GstRegistryChunkTypeFindFactory);
GstDeviceProviderFactory *factory = GST_DEVICE_PROVIDER_FACTORY (feature);
/* Initialize with zeroes because of struct padding and
- * valgrind complaining about copying unitialized memory
+ * valgrind complaining about copying uninitialized memory
*/
tff = g_slice_new0 (GstRegistryChunkDeviceProviderFactory);
chk =
gst_structure_to_string (factory->metadata));
} else if (GST_IS_TRACER_FACTORY (feature)) {
/* Initialize with zeroes because of struct padding and
- * valgrind complaining about copying unitialized memory
+ * valgrind complaining about copying uninitialized memory
*/
pf = g_slice_new0 (GstRegistryChunkPluginFeature);
pf_size = sizeof (GstRegistryChunkPluginFeature);
* negative stream-time.
*
* This function is typically used by elements that need to synchronize buffers
- * against the clock or eachother.
+ * against the clock or each other.
*
* @position can be any value and the result of this function for values outside
* of the segment is extrapolated.
* negative running-time.
*
* This function is typically used by elements that need to synchronize buffers
- * against the clock or eachother.
+ * against the clock or each other.
*
* @position can be any value and the result of this function for values outside
* of the segment is extrapolated.
if (stream_id)
stream->stream_id = g_strdup (stream_id);
else {
- /* Create a randoom stream_id if NULL */
+ /* Create a random stream_id if NULL */
GST_FIXME_OBJECT (stream, "Creating random stream-id, consider "
"implementing a deterministic way of creating a stream-id");
stream->stream_id =
g_return_val_if_fail (tag != NULL, NULL);
info = gst_tag_lookup (tag);
if (!info) {
- GST_WARNING ("Uknown tag: %s", tag);
+ GST_WARNING ("Unknown tag: %s", tag);
return tag;
}
g_warning ("%s: %s", G_STRLOC, error);
g_free (error);
/* we purposely leak the value here, it might not be
- * in a sane state if an error condition occoured
+ * in a sane state if an error condition occurred
*/
return;
}
* @GST_TRACER_VALUE_SCOPE_ELEMENT: the value is related to an #GstElement
* @GST_TRACER_VALUE_SCOPE_PAD: the value is related to a #GstPad
*
- * Tracing record will contain fields that contain a meassured value or extra
+ * Tracing record will contain fields that contain a measured value or extra
* meta-data. One such meta data are values that tell where a measurement was
* taken. This enumerating declares to which scope such a meta data field
* relates to. If it is e.g. %GST_TRACER_VALUE_SCOPE_PAD, then each of the log
* The user can activate tracers by setting the environment variable GST_TRACE
* to a ';' separated list of tracers.
*
- * Note that instanciating tracers at runtime is possible but is not thread safe
+ * Note that instantiating tracers at runtime is possible but is not thread safe
* and needs to be done before any pipeline state is set to PAUSED.
*/
* @title: GstTypeFindFactory
* @short_description: Information about registered typefind functions
*
- * These functions allow querying informations about registered typefind
+ * These functions allow querying information 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>.
* @short_description: URI parsing and manipulation.
*
* A #GstUri object can be used to parse and split a URI string into its
- * constituant parts. Two #GstUri objects can be joined to make a new #GstUri
+ * constituent parts. Two #GstUri objects can be joined to make a new #GstUri
* using the algorithm described in RFC3986.
*/
* reference to the new one is used instead. A value if %NULL for @query_table
* will remove the query string from the URI.
*
- * Returns: %TRUE if the new table was sucessfully used for the query table.
+ * Returns: %TRUE if the new table was successfully used for the query table.
*
* Since: 1.6
*/
* indicates that the key has no associated value, but will still be present in
* the query string.
*
- * Returns: %TRUE if the query table was sucessfully updated.
+ * Returns: %TRUE if the query table was successfully updated.
*
* Since: 1.6
*/
* Get the media fragment table from the URI, as defined by "Media Fragments URI 1.0".
* Hash table returned by this API is a list of "key-value" pairs, and the each
* pair is generated by splitting "URI fragment" per "&" sub-delims, then "key"
- * and "value" are splitted by "=" sub-delims. The "key" returned by this API may
+ * and "value" are split by "=" sub-delims. The "key" returned by this API may
* be undefined keyword by standard.
* A value may be %NULL to indicate that the key should appear in the fragment
* string in the URI, but does not have a value. Free the returned #GHashTable
return FALSE;
} else {
/* no need to release any request pad as the case of unset destpatname and
- * destpad being a requst pad has already been taken care of when looking
+ * destpad being a request pad has already been taken care of when looking
* though the destination pads above */
if (destpad) {
gst_object_unref (destpad);
* @debug: (in) (allow-none): an additional debug information string, or %NULL
*
* A default error function that uses g_printerr() to display the error message
- * and the optional debug sting..
+ * and the optional debug string..
*
* The default handler will simply print the error string using g_print.
*/
}
/* "Pure" variant of gst_value_compare which is guaranteed to
- * not have list arguments and therefore does basic comparisions
+ * not have list arguments and therefore does basic comparisons
*/
static inline gint
_gst_value_compare_nolist (const GValue * value1, const GValue * value2)
/*************************************************************
* Grammar explanation: (cont'd)
-* a _chain_ is a list of _elementary_s that have _link_s inbetween
+* a _chain_ is a list of _elementary_s that have _link_s in between
* which are represented through infix-notation.
*
* fakesrc ! sometransformation ! fakesink
#!/bin/sh
#
-# Check that the code follows a consistant code style
+# Check that the code follows a consistent code style
#
# Check for existence of indent, and error out if not present.
/* If change are not acceptable, fallback to generic pool */
if (!gst_buffer_pool_config_validate_params (config, outcaps, size, min,
max)) {
- GST_DEBUG_OBJECT (trans, "unsuported pool, making new pool");
+ GST_DEBUG_OBJECT (trans, "unsupported pool, making new pool");
gst_object_unref (pool);
pool = gst_buffer_pool_new ();
}
}
-/* Given @caps calcultate the size of one unit.
+/* Given @caps calculate the size of one unit.
*
* For video caps, this is the size of one frame (and thus one buffer).
* For audio caps, this is the size of one sample.
*
* Updates the srcpad caps and send the caps downstream. This function
* can be used by subclasses when they have already negotiated their caps
- * but found a change in them (or computed new informations). This way,
- * they can notify downstream about that change without loosing any
+ * but found a change in them (or computed new information). This way,
+ * they can notify downstream about that change without losing any
* buffer.
*
* Returns: %TRUE if the caps could be send downstream %FALSE otherwise
*/
/* NOTE allowing to change comparison seems not advisable;
no known use-case, and collaboration with default algorithm is unpredictable.
-If custom compairing/operation is needed, just use a collect function of
+If custom comparing/operation is needed, just use a collect function of
your own */
void
gst_collect_pads_set_compare_function (GstCollectPads * pads,
* @pos: position in the buffer
* @segment: last segment received.
* @dts: the signed version of the DTS converted to running time. To access
- * this memeber, use %GST_COLLECT_PADS_DTS macro. (Since 1.6)
+ * this member, use %GST_COLLECT_PADS_DTS macro. (Since 1.6)
*
* Structure used by the collect_pads.
*/
* * %GST_FLOW_OK: otherwise
*
* %GST_FLOW_ERROR or below, GST_FLOW_NOT_NEGOTIATED and GST_FLOW_FLUSHING are
- * returned immediatelly from the gst_flow_combiner_update_flow() function.
+ * returned immediately from the gst_flow_combiner_update_flow() function.
*
* Since: 1.4
*/
/**
* gst_index_commit:
* @index: the index to commit
- * @id: the writer that commited the index
+ * @id: the writer that committed the index
*
* Tell the index that the writer with the given id is done
* with this index and is not going to write any more entries
* gst_index_add_associationv:
* @index: the index to add the entry to
* @id: the id of the index writer
- * @flags: optinal flags for this entry
+ * @flags: optional flags for this entry
* @n: number of associations
* @list: (array length=n): list of associations
*
* gst_index_add_association:
* @index: the index to add the entry to
* @id: the id of the index writer
- * @flags: optinal flags for this entry
+ * @flags: optional flags for this entry
* @format: the format of the value
* @value: the value
* @...: other format/value pairs or 0 to end the list
* GstCheckLogFilterFunc:
* @log_domain: the log domain of the message
* @log_level: the log level of the message
- * @message: the message that has occured
+ * @message: the message that has occurred
* @user_data: user data
*
* A function that is called for messages matching the filter added by
* @h: a #GstHarness
* @srcpad: a #GstPad to link to the harness sinkpad
*
- * Links the specifed #GstPad the @GstHarness sinkpad. This can be useful if
+ * Links the specified #GstPad the @GstHarness sinkpad. This can be useful if
* perhaps the srcpad did not exist at the time of creating the harness,
* like a demuxer that provides a sometimes-pad after receiving data.
*
* @h: a #GstHarness
* @sinkpad: a #GstPad to link to the harness srcpad
*
- * Links the specifed #GstPad the @GstHarness srcpad.
+ * Links the specified #GstPad the @GstHarness srcpad.
*
* MT safe.
*
* 3: Release the #GstClockID wait.
* Together, this provides an easy way to not have to think about the details
* around clocks and time, but still being able to write deterministic tests
- * that are dependant on this. A "crank" can be though of as the notion of
+ * that are dependent on this. A "crank" can be though of as the notion of
* manually driving the clock forward to its next logical step.
*
* MT safe.
*
* This will set the harnessed #GstElement to %GST_STATE_PLAYING.
* #GstElements without a sink-#GstPad and with the %GST_ELEMENT_FLAG_SOURCE
- * flag set is concidered a src #GstElement
+ * flag set is considered a src #GstElement
* Non-src #GstElements (like sinks and filters) are automatically set to
* playing by the #GstHarness, but src #GstElements are not to avoid them
* starting to produce buffers.
* By adding a src-type #GstElement, it is then easy to use functions like
* gst_harness_push_from_src or gst_harness_src_crank_and_push_many
* to provide your harnessed element with input. The @has_clock_wait variable
- * is a greate way to control you src-element with, in that you can have it
+ * is a great way to control you src-element with, in that you can have it
* produce a buffer for you by simply cranking the clock, and not have it
* spin out of control producing buffers as fast as possible.
*
* responses the element output might create in sink elements. An example might
* be an existing sink providing some analytical data on the input it receives that
* can be useful to your testing. If the goal is to test a sink-element itself,
- * this is better acheived using gst_harness_new directly on the sink.
+ * this is better achieved using gst_harness_new directly on the sink.
*
* If a sink-harness already exists it will be replaced.
*
*
* Note that if a setup function fails, the remaining setup functions
* will be omitted, as will the test case and the teardown functions.
- * If a teardown function fails the remaining teardown functins will be
+ * If a teardown function fails the remaining teardown functions will be
* omitted.
*
* @param tc test case to add unchecked fixture setup/teardown to
*
* Note that if a setup function fails, the remaining setup functions
* will be omitted, as will the test and the teardown functions. If a
- * teardown function fails the remaining teardown functins will be
+ * teardown function fails the remaining teardown functions will be
* omitted.
*
* @param tc test case to add checked fixture setup/teardown to
{
enum test_result rtype; /* Type of result */
enum ck_result_ctx ctx; /* When the result occurred */
- char *file; /* File where the test occured */
+ char *file; /* File where the test occurred */
int line; /* Line number where the test occurred */
int iter; /* The iteration value for looping tests */
int duration; /* duration of this test in microseconds */
/* linear interpolation */
-/* smoothes inbetween values */
+/* smoothes in between values */
static inline gdouble
_interpolate_linear (GstClockTime timestamp1, gdouble value1,
GstClockTime timestamp2, gdouble value2, GstClockTime timestamp)
* @self: The #GstTimedValueControlSource on which a #GstTimedValue has changed
* @timed_value: The #GstTimedValue where the value changed
*
- * Emited right after the new value has been set on @timed_signals
+ * Emitted right after the new value has been set on @timed_signals
*
* Since: 1.6
*/
* added
* @timed_value: The newly added #GstTimedValue
*
- * Emited right after the new value has been added to @self
+ * Emitted right after the new value has been added to @self
*
* Since: 1.6
*/
* removed
* @timed_value: The removed #GstTimedValue
*
- * Emited when @timed_value is removed from @self
+ * Emitted when @timed_value is removed from @self
*
* Since: 1.6
*/
*
* Check if the GStreamer PTP clock subsystem is initialized.
*
- * Returns: %TRUE if the GStreamer PTP clock subsystem is intialized.
+ * Returns: %TRUE if the GStreamer PTP clock subsystem is initialized.
*
* Since: 1.6
*/
g_list_free (events);
}
-/* Ouput buffer preparation ... if the buffer has no caps, and our allowed
+/* Output buffer preparation ... if the buffer has no caps, and our allowed
* output caps is fixed, then send the caps downstream, making sure caps are
* sent before segment event.
*
* @title: concat
* @see_also: #GstFunnel
*
- * Concatenates streams together to one continous stream.
+ * Concatenates streams together to one continuous stream.
*
* All streams but the current one are blocked until the current one
* finished with %GST_EVENT_EOS. Then the next stream is enabled, while
- * keeping the running time continous for %GST_FORMAT_TIME segments or
- * keeping the segment continous for %GST_FORMAT_BYTES segments.
+ * keeping the running time continuous for %GST_FORMAT_TIME segments or
+ * keeping the segment continuous for %GST_FORMAT_BYTES segments.
*
* Streams are switched in the order in which the sinkpads were requested.
*
/* We know no duration */
segment.duration = -1;
- /* Update segment values to be continous with last stream */
+ /* Update segment values to be continuous with last stream */
if (self->format == GST_FORMAT_TIME) {
segment.base += self->current_start_offset;
} else {
*
* The active pad may push more buffers than what is currently displayed/consumed
* and when changing pads those buffers will be discarded and the only way to
- * reactivate that pad without loosing the already consumed buffers is to enable cache.
+ * reactivate that pad without losing the already consumed buffers is to enable cache.
*/
g_object_class_install_property (gobject_class, PROP_CACHE_BUFFERS,
g_param_spec_boolean ("cache-buffers", "Cache Buffers",
* This is currently not yet implemented.
* Since we dynamically scale the queue buffer size up to the limits but avoid
* going above the max-size-buffers when we can, we don't really need this
- * aditional extra size. */
+ * additional extra size. */
#define DEFAULT_EXTRA_SIZE_BYTES 10 * 1024 * 1024 /* 10 MB */
#define DEFAULT_EXTRA_SIZE_BUFFERS 5
#define DEFAULT_EXTRA_SIZE_TIME 3 * GST_SECOND
gst_object_unref (peer_pad);
/* Allocation Params:
- * store the maximum alignment, prefix and pading, but ignore the
+ * store the maximum alignment, prefix and padding, but ignore the
* allocators and the flags which are tied to downstream allocation */
count = gst_query_get_n_allocation_params (query);
for (i = 0; i < count; i++) {
{
GstEvent *event;
- /* Update caps field immediatly so that caps queries and properties can be
+ /* Update caps field immediately so that caps queries and properties can be
* honored in all "have-type" signal handlers.
*/
GST_OBJECT_LOCK (typefind);
GST_OBJECT_UNLOCK (typefind);
- /* probability is good enough too, so let's make it known ... emiting this
+ /* probability is good enough too, so let's make it known ... emitting this
* signal calls our object handler which sets the caps. */
/* Set to MODE_NORMAL before emitting have-type, in case it triggers a seek */
typefind->mode = MODE_NORMAL;
goto pause;
}
- GST_DEBUG ("Emiting found caps %" GST_PTR_FORMAT, found_caps);
+ GST_DEBUG ("Emitting found caps %" GST_PTR_FORMAT, found_caps);
/* Set to MODE_NORMAL before emitting have-type, in case it triggers a seek */
typefind->mode = MODE_NORMAL;
gst_type_find_element_emit_have_type (typefind, probability, found_caps);
gst_tracing_register_hook (tracer, "pad-push-list-pre",
G_CALLBACK (do_push_buffer_pre));
- /* while in pull mode, pre/post will happend before and after the upstream
+ /* while in pull mode, pre/post will happen before and after the upstream
* pull_range call is made, so it already only account for the upstream
* processing time. As a side effect, in pull mode, we can measure the
* source processing latency, while in push mode, we can't */
esac
# http://www.gnuplot.info/docs/node341.html (terminal options)
case $format in
- # this doen't like fonts
+ # this doesn't like fonts
png) echo "set term png truecolor font \"Sans,7\" size $plot_width,$plot_height";;
# pdf makes a new page for each plot :/
pdf) echo "set term pdf color font \"Sans,7\" size $page_with,$page_height";;
/*
* Push GAP events into funnel to forward sticky events.
- * Funnel element shoud also treat GAP events likes buffers.
+ * Funnel element should also treat GAP events likes buffers.
* For example, funnel can be used for internal subtitle with streamiddemux.
* +--------------------------------------------------------------------------+
* | playbin +--------------------------------+ |
if (active) {
fail_unless (gst_pad_push_event (pad, gst_event_new_eos ()));
} else {
- /* The non-active pads will block when receving eos, so we need to do it
+ /* The non-active pads will block when receiving eos, so we need to do it
* from a separate thread. This makes this test racy, but it should only
* cause false positives, not false negatives */
GThread *t = g_thread_new ("selector-test-push-eos",
g_object_get (td.demux, "active-pad", &active_srcpad, NULL);
fail_unless (active_srcpad != NULL, "Failed to generate a srcpad");
- fail_unless (td.srcpad_cnt == 1, "pad-added signal has not emmited");
+ fail_unless (td.srcpad_cnt == 1, "pad-added signal has not emitted");
GST_DEBUG ("Releasing mysink and mysrc");
gst_pad_set_active (td.mysink[0], FALSE);
g_object_get (td.demux, "active-pad", &active_srcpad, NULL);
fail_unless (active_srcpad == NULL, "srcpad has created unexpectedly");
- fail_unless (td.srcpad_cnt == 0, "pad-added signal is emmited unexpectedly");
+ fail_unless (td.srcpad_cnt == 0, "pad-added signal is emitted unexpectedly");
GST_DEBUG ("Releasing mysink and mysrc");
gst_pad_set_active (td.mysink[0], FALSE);
gst_buffer_unmap (sub, &sinfo);
gst_buffer_unref (sub);
- /* test if metadata is coppied, not a complete buffer copy so only the
+ /* test if metadata is copied, not a complete buffer copy so only the
* timestamp and offset fields are copied. */
sub = gst_buffer_copy_region (buffer, GST_BUFFER_COPY_ALL, 0, 1);
fail_if (sub == NULL, "copy_region of buffer returned NULL");
"subbuffer has wrong offset end");
gst_buffer_unref (sub);
- /* test if metadata is coppied, a complete buffer is copied so all the timing
+ /* test if metadata is copied, a complete buffer is copied so all the timing
* fields should be copied. */
sub = gst_buffer_copy_region (buffer, GST_BUFFER_COPY_ALL, 0, 4);
fail_if (sub == NULL, "copy_region of buffer returned NULL");
gst_memory_unmap (sub, &sinfo);
gst_memory_unref (sub);
- /* test if metadata is coppied, not a complete memory copy so only the
+ /* test if metadata is copied, not a complete memory copy so only the
* timestamp and offset fields are copied. */
sub = gst_memory_share (memory, 0, 1);
fail_if (sub == NULL, "share of memory returned NULL");
"submemory has wrong size");
gst_memory_unref (sub);
- /* test if metadata is coppied, a complete memory is copied so all the timing
+ /* test if metadata is copied, a complete memory is copied so all the timing
* fields should be copied. */
sub = gst_memory_share (memory, 0, 4);
fail_if (sub == NULL, "share of memory returned NULL");
copy = gst_memory_copy (memory, 0, -1);
ASSERT_MINI_OBJECT_REFCOUNT (memory, "memory", 1);
ASSERT_MINI_OBJECT_REFCOUNT (copy, "copy", 1);
- /* memorys are copied and must point to different memory */
+ /* memory is copied and must point to different memory */
fail_if (memory == copy);
fail_unless (gst_memory_map (memory, &info, GST_MAP_READ));
static gpointer
_my_opaque_mem_map (MyOpaqueMemory * mem, gsize maxsize, GstMapFlags flags)
{
- /* the subclass is reponsible for logging any error, by design choice and for
+ /* the subclass is responsible for logging any error, by design choice and for
* testing purpose MyOpaqueMemory never logs any trace */
return NULL;
}
gst_debug_add_log_function (_custom_log_func, NULL, NULL);
/* Ensure that the map does not log any error on failure. It has to fail
- * because the custom opaque memory here is desgined to not be mappable. */
+ * because the custom opaque memory here is designed to not be mappable. */
fail_if (gst_memory_map (mem, &info, GST_MAP_READ));
fail_if (info.data != NULL);
fail_if (info.size != 0);
fail_unless (stream3 != NULL);
gst_object_unref (stream3);
- /* Shoul fail */
+ /* Should fail */
ASSERT_CRITICAL (gst_message_streams_selected_get_stream (message, 1));
gst_object_unref (res);
_probe_handler, GINT_TO_POINTER (GST_PAD_PROBE_DROP), NULL);
fail_unless (gst_pad_push_event (src,
gst_event_new_segment (&dummy_segment)) == TRUE);
- /* Queries should stil fail */
+ /* Queries should still fail */
query = gst_query_new_duration (GST_FORMAT_TIME);
fail_unless (gst_pad_peer_query (src, query) == FALSE);
ASSERT_MINI_OBJECT_REFCOUNT (query, "query", 1);
}
fail_unless (gst_pad_push_event (srcpad, GST_EVENT_CAST (data)));
} else if (GST_IS_QUERY (data)) {
- /* we don't care whether the query actualy got handled */
+ /* we don't care whether the query actually got handled */
gst_pad_peer_query (srcpad, GST_QUERY_CAST (data));
gst_query_unref (GST_QUERY_CAST (data));
} else {
static gboolean
_quit (GMainLoop * ml)
{
- GST_DEBUG ("QUITING ML");
+ GST_DEBUG ("QUITTING ML");
g_main_loop_quit (ml);
return G_SOURCE_REMOVE;
if (count == 0)
gst_element_set_state (pipeline, GST_STATE_PLAYING);
- /* Now make sure the seek happend */
+ /* Now make sure the seek happened */
carry_on = TRUE;
do {
message = gst_bus_timed_pop (bus, -1);
g_object_set (playbin, "uri", uri, NULL);
g_free (uri);
- /* create and event loop and feed gstreamer bus mesages to it */
+ /* create an event loop and feed gstreamer bus messages to it */
loop = g_main_loop_new (NULL, FALSE);
bus = gst_element_get_bus (playbin);
projects / platform / upstream / gstreamer.git / commitdiff