mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2024-06-20 15:00:43 +00:00
Code Issues 1 Projects Releases Wiki Activity

Fix typos in comments and docs

Browse source 
Found via `codespell`

https://bugzilla.gnome.org/show_bug.cgi?id=795610
This commit is contained in:
luz.paz 2018-04-27 12:40:31 -04:00 committed by Tim-Philipp Müller
parent bad751b22f
commit 4a402c1c7d
130 changed files with 264 additions and 264 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
configure.ac
View file

@ -947,7 +947,7 @@ dnl *** finalize CFLAGS, LDFLAGS, LIBS
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

4
docs/libs/gstreamer-libs-docs.sgml
View file

@ -27,10 +27,10 @@
</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" />

10
docs/random/TODO-pre-0.9
View file

@ -4,23 +4,23 @@ TODO:
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)

4
docs/random/autoplug1
View file

@ -154,7 +154,7 @@ ex.
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.
(------------------------------------) (----------
@ -180,7 +180,7 @@ Problems:
---------
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

2
docs/random/autoplug2
View file

@ -236,7 +236,7 @@ now we loop over all the list and try to add the remaining elements
(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.

2
docs/random/bbb/streamselection
View file

@ -61,7 +61,7 @@ extremely useful here, and requires little code in the switch-like
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.

8
docs/random/caps
View file

@ -75,7 +75,7 @@ pad capabilities.
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:
@ -101,7 +101,7 @@ factory:
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
@ -128,7 +128,7 @@ An element would still list its mime type using:
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
@ -138,7 +138,7 @@ Elements that accept the src mime-type are tried by giving it a buffer.
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

2
docs/random/caps2
View file

@ -130,7 +130,7 @@ The pad template caps should be the union of caps a pad supports
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,

4
docs/random/company/clocks
View file

@ -60,7 +60,7 @@ Providers are elements that can provide timing information and therefore provide
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
@ -77,7 +77,7 @@ GstClockTime gst_clock_get_time (GstClock *clock);
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);

4
docs/random/company/gstdata
View file

@ -64,7 +64,7 @@ struct _GstMyData {
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));
@ -206,7 +206,7 @@ FIXME: Write more, when sure how to do this.
Upstream events
===============
These will be discussed in a seperate doc.
These will be discussed in a separate doc.

2
docs/random/company/gstparse
View file

@ -93,7 +93,7 @@ automatically means the element directly in front of / after the link is used
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

12
docs/random/company/gvadec.txt
View file

@ -36,7 +36,7 @@ Although the GStreamer framework's focus is multimedia processing, the core
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.
@ -45,7 +45,7 @@ Plugins
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.
@ -53,7 +53,7 @@ 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)
@ -146,7 +146,7 @@ elements implementing them.
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.
@ -166,7 +166,7 @@ GST_STATE_NULL to GST_STATE_READY
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
@ -177,7 +177,7 @@ the element is ready to start.
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.

2
docs/random/company/tagging
View file

@ -1,7 +1,7 @@
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.

2
docs/random/company/time
View file

@ -1,7 +1,7 @@
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.

2
docs/random/ds/0.9-planning2
View file

@ -69,7 +69,7 @@ plans:
- 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.

4
docs/random/dynpads
View file

@ -2,7 +2,7 @@ Dynamic pads are pads that are created while the element is playing.
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
@ -33,7 +33,7 @@ padtemplate provided by the compressor src pad and connect the
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

2
docs/random/ensonic/distributed.txt
View file

@ -9,7 +9,7 @@ respective machine.
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 ==

2
docs/random/ensonic/dparams.txt
View file

@ -10,5 +10,5 @@ $Id$
* 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

20
docs/random/ensonic/draft-bufferpools.txt
View file

@ -1,7 +1,7 @@
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
@ -20,24 +20,24 @@ Problems
- 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:
@ -48,12 +48,12 @@ 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
@ -65,7 +65,7 @@ Bufferpools owners need to handle caps changes to keep the queued buffers valid
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.
@ -106,7 +106,7 @@ There are more attributes on buffers needed to reduce the overhead even more:
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

2
docs/random/ensonic/draft-registry-change-hooks.txt
View file

@ -1,7 +1,7 @@
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

4
docs/random/ensonic/dynlink.txt
View file

@ -73,13 +73,13 @@ gst_pads_insert_link (e1.src, e4.sink, e5.src, e6.sink);
= 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

10
docs/random/ensonic/embedded.txt
View file

@ -7,8 +7,8 @@ For avidemux I currently have a big patch doing memory optimized index handling.
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
@ -20,13 +20,13 @@ encapsulated in the indexer strategy.
== 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)

2
docs/random/ensonic/interfaces.txt
View file

@ -45,7 +45,7 @@ $Id$
* 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

2
docs/random/ensonic/lazycaps.txt
View file

@ -54,7 +54,7 @@ void gst_caps_merge_structure (GstCaps *caps,
- 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

2
docs/random/ensonic/logging.txt
View file

@ -2,7 +2,7 @@ $Id$
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:

2
docs/random/ensonic/media-device-daemon.txt
View file

@ -4,7 +4,7 @@ components
================================================================================
- 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

6
docs/random/ensonic/profiling.txt
View file

@ -13,7 +13,7 @@ $Id$
= 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
@ -23,7 +23,7 @@ $Id$
* 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:
@ -66,7 +66,7 @@ $Id$
* 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

2
docs/random/error
View file

@ -55,5 +55,5 @@ Some notes on the error handling introduced after 0.7.3
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.

14
docs/random/events
View file

@ -56,7 +56,7 @@ There are 3 different directions an event can be processed.
* 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
@ -142,7 +142,7 @@ from these infos. (eg converting stream length in bytes to song length in
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
@ -177,7 +177,7 @@ References to events are handled similar to buffers. An element receives an even
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
@ -215,7 +215,7 @@ Use Cases
---------
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
@ -245,7 +245,7 @@ not important for the example.
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
@ -253,7 +253,7 @@ not important for the example.
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.
@ -271,7 +271,7 @@ not important for the example.
- 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.

4
docs/random/gdp
View file

@ -1,8 +1,8 @@
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)

4
docs/random/matth/scheduling.txt
View file

@ -5,8 +5,8 @@
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.

2
docs/random/negotiation
View file

@ -270,7 +270,7 @@ Other junk:
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

2
docs/random/old/ChangeLog.gstreamer
View file

@ -14060,7 +14060,7 @@
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.

2
docs/random/omega/TODO-0.1.0
View file

@ -40,7 +40,7 @@ Finish LADSPA plugin to data-moving stage
things to remember for the anouncement:
things to remember for the announcement:
---------------------------------------
Build requirements list:

10
docs/random/omega/caps2
View file

@ -57,7 +57,7 @@ Again from the plugin registry we find an element audiosink that has appropriate
};
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:
@ -106,10 +106,10 @@ changed:
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",
@ -231,7 +231,7 @@ following caps:
};
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

4
docs/random/omega/plan-generation
View file

@ -5,7 +5,7 @@ Plan generation happens at transition from NULL to READY (and PLAYING to READY r
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).
@ -33,7 +33,7 @@ furtuer down the hierarchy, until everything is covered.
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

2
docs/random/omega/sched-commit1
View file

@ -25,7 +25,7 @@ now have:
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)

2
docs/random/omega/sched2
View file

@ -4,7 +4,7 @@ header stuff to do various checking of flags. Unfortunately, because of the sel
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.

14
docs/random/phonon-gst
View file

@ -97,14 +97,14 @@ Questions
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
@ -189,7 +189,7 @@ Phonon::AudioEffect/Phonon::VideoEffect
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
@ -239,7 +239,7 @@ Phonon::ByteStream
- 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/
@ -254,12 +254,12 @@ 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

2
docs/random/plan-0.11.txt
View file

@ -112,7 +112,7 @@ First attempt at making a list of tasks in roughly chronological order.
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)

2
docs/random/plugins
View file

@ -25,7 +25,7 @@ element factories provide the core library with elements (duh)
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)

2
docs/random/porting-to-1.0.txt
View file

@ -409,7 +409,7 @@ CHANGES
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.

2
docs/random/queue
View file

@ -9,7 +9,7 @@
// 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++;

10
docs/random/rtp
View file

@ -12,11 +12,11 @@ Suggested implementation:
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):
@ -24,13 +24,13 @@ To handle variable types, the following would work (the UDP part left out for cl
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.
@ -40,5 +40,5 @@ udpsrc ! rtp-mp3 ! mp3decode ! osssink
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.

4
docs/random/thomasvs/0.10
View file

@ -47,7 +47,7 @@ gst-plugins-base
- 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:
@ -58,7 +58,7 @@ gst-plugins-base
- 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

2
docs/random/thomasvs/packaging
View file

@ -24,7 +24,7 @@ to a lot of projects, including GLib and the kernel.
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

4
docs/random/types
View file

@ -19,11 +19,11 @@ A plugin init function would take this typefactory and hand it to the
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

4
docs/random/types2
View file

@ -97,7 +97,7 @@ the equivalence of both types, even it they have a different mime type.
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:
@ -223,7 +223,7 @@ that it can handle all sorts of video/mpeg data.
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:

4
docs/random/types3
View file

@ -79,7 +79,7 @@ mpg123: an mpeg audio decoder.
// 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
};
@ -128,7 +128,7 @@ mpeg2dec: an mpeg video decoder that can do mpeg1 and mpeg2.
static GstTypeFactory mpegfactory = {
"video/mpeg", // major type
".mpg .mpeg", // extenstions
".mpg .mpeg", // extensions
NULL, // typefind function
};

2
docs/random/uraeus/gstreamer_and_midi.txt
View file

@ -319,7 +319,7 @@ KAR files are standard MIDI files that also contain a stream with lyrics, for ka
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:

4
docs/random/wtay/CORBA
View file

@ -19,7 +19,7 @@ of allowing objects to live in other contexts, languages and
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.
@ -48,7 +48,7 @@ you to, for example, merge a pipeline with a document in one
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.

2
docs/random/wtay/autoplug2
View file

@ -15,7 +15,7 @@ serious shortcommings:
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.

2
docs/random/wtay/caps-negociation
View file

@ -193,7 +193,7 @@ of the pads negotiation functions returns the caps unmodified.
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

2
docs/random/wtay/capsnego2
View file

@ -199,7 +199,7 @@ in this case, mad can both send "int" audio samples and "float" samples.
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.

6
docs/random/wtay/capsnego2-docs
View file

@ -31,7 +31,7 @@ a key, which is always a string constant (internally converted to a GQuark)
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)
@ -186,7 +186,7 @@ If the intersection is a fixed caps, this means there is only one possible media
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,
@ -275,7 +275,7 @@ Pad connect functions
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.

4
docs/random/wtay/clocking
View file

@ -18,7 +18,7 @@ Clocks
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.
@ -150,7 +150,7 @@ if no Src elements exist with a clock, select a random clock from the
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

8
docs/random/wtay/eos2
View file

@ -96,12 +96,12 @@ case 3)
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,
@ -136,12 +136,12 @@ case 4)
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.

4
docs/random/wtay/events
View file

@ -28,7 +28,7 @@ only travel in one direction.
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.
@ -73,7 +73,7 @@ Possible candidates for events
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

4
docs/random/wtay/events3
View file

@ -28,7 +28,7 @@ only travel in one direction.
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.
@ -145,7 +145,7 @@ are supposed to handle them.
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

4
docs/random/wtay/interactivity
View file

@ -6,7 +6,7 @@ Possible application: DVD navigation, flash,...
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
@ -75,7 +75,7 @@ GST_CAPS_NEW (
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

6
docs/random/wtay/messages
View file

@ -12,13 +12,13 @@ interesting information for the user app or for its parent.
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:
@ -42,7 +42,7 @@ every signal in each element this would work somewhat.
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.

10
docs/random/wtay/namespaces
View file

@ -28,7 +28,7 @@ or soon with the proposed 'new' standard of the W3C; Schemas.
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
@ -53,7 +53,7 @@ Were a typical XML document without namespaces would look like:
</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/">
@ -98,7 +98,7 @@ editor as an example. The editor will insert XML tags inside each
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:
@ -154,7 +154,7 @@ The XML save procedure on a GstObject is performed with:
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
@ -174,7 +174,7 @@ freshly loaded objects.
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

2
docs/random/wtay/negotiation3
View file

@ -224,7 +224,7 @@ Default implementations
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)

4
docs/random/wtay/padprobes
View file

@ -4,8 +4,8 @@ PadProbes
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?

4
docs/random/wtay/pipelineinfo
View file

@ -205,7 +205,7 @@ always performed relative to 0, so if we convert track2 to bytes, we
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.
@ -260,7 +260,7 @@ Several reasons:
- 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.

8
docs/random/wtay/plugin_guidelines
View file

@ -253,7 +253,7 @@ complicated case
* 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).
@ -267,8 +267,8 @@ NOTES:
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
@ -284,7 +284,7 @@ Calling yield, pulling, pushing can potentially never return because a state cha
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.

2
docs/random/wtay/registry
View file

@ -1,7 +1,7 @@
Requirements
------------
- plugable backends:
- pluggable backends:
- XML
- flat file

2
docs/random/wtay/scheduling_ideas
View file

@ -254,7 +254,7 @@ Grouping
* 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

16
docs/random/wtay/threading
View file

@ -46,7 +46,7 @@ Fixing Threading
- 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:
@ -213,7 +213,7 @@ Fixing Threading
+---------+ +-----------------------+
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:
@ -250,7 +250,7 @@ Fixing Threading
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.
@ -345,7 +345,7 @@ Fixing Threading
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
@ -405,7 +405,7 @@ Fixing Threading
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
@ -478,7 +478,7 @@ Fixing Threading
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);
@ -529,7 +529,7 @@ Fixing Threading
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
@ -580,7 +580,7 @@ Fixing Threading
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.

2
docs/random/wtay/threads_hilevel
View file

@ -168,5 +168,5 @@ TODO
----
- review
- figure all state change scenarios occuring in code marked with (*)
- figure all state change scenarios occurring in code marked with (*)

2
docs/random/wtay/timecache
View file

@ -7,7 +7,7 @@ an index of possible seek positions (in time, bytes, samples, ...).
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

2
gst/gst.c
View file

@ -633,7 +633,7 @@ gst_register_core_elements (GstPlugin * plugin)
/*
* this bit handles:
* - initalization of threads if we use them
* - initialization of threads if we use them
* - log handler
* - initial output
* - initializes gst_format

10
gst/gstbin.c
View file

@ -2573,7 +2573,7 @@ gst_bin_element_set_state (GstBin * bin, GstElement * element,
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))) {
@ -3058,12 +3058,12 @@ done:
/* 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);
}
@ -3518,7 +3518,7 @@ bin_do_eos (GstBin * bin)
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
@ -3952,7 +3952,7 @@ gst_bin_handle_message_func (GstBin * bin, GstMessage * message)
/* 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

2
gst/gstcapsfeatures.c
View file

@ -801,7 +801,7 @@ gst_caps_features_add_id (GstCapsFeatures * features, GQuark feature)
}
/* 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

4
gst/gstdebugutils.c
View file

@ -1,7 +1,7 @@
/* 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
@ -21,7 +21,7 @@
/* 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

2
gst/gstdebugutils.h
View file

@ -1,7 +1,7 @@
/* 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

4
gst/gstdevice.h
View file

@ -44,7 +44,7 @@ typedef struct _GstDevicePrivate GstDevicePrivate;
/**
* GstDevice:
* @parent: The parent #GstObject strucuture.
* @parent: The parent #GstObject structure.
*
* A device object.
*
@ -62,7 +62,7 @@ struct _GstDevice {
/**
* 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

2
gst/gstdeviceprovider.c
View file

@ -26,7 +26,7 @@
* @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

6
gst/gstelement.c
View file

@ -1734,7 +1734,7 @@ gst_element_class_get_request_pad_template (GstElementClass *
}
/* 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,
@ -2986,14 +2986,14 @@ gst_element_change_state (GstElement * element, GstStateChange transition)
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;

2
gst/gstelement.h
View file

@ -28,7 +28,7 @@
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;

2
gst/gstevent.c
View file

@ -1665,7 +1665,7 @@ gst_event_set_stream (GstEvent * event, GstStream * stream)
/**
* 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.
*

2
gst/gstinfo.h
View file

@ -253,7 +253,7 @@ struct _GstDebugCategory {
* 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.
*

2
gst/gstmemory.c
View file

@ -321,7 +321,7 @@ lock_failed:
}
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);

2
gst/gstmessage.h
View file

@ -193,7 +193,7 @@ GST_API GType _gst_message_type;
#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))

2
gst/gstminiobject.c
View file

@ -343,7 +343,7 @@ gst_mini_object_ref (GstMiniObject * mini_object)
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);
*/

4
gst/gstobject.c
View file

@ -1424,7 +1424,7 @@ gst_object_get_g_value_array (GstObject * object, const gchar * property_name,
*
* 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
@ -1450,7 +1450,7 @@ gst_object_get_control_rate (GstObject * object)
*
* 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

6
gst/gstpad.c
View file

@ -604,7 +604,7 @@ restart:
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;
@ -1444,7 +1444,7 @@ gst_pad_add_probe (GstPad * pad, GstPadProbeType mask,
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;
@ -1461,7 +1461,7 @@ gst_pad_add_probe (GstPad * pad, GstPadProbeType mask,
/* 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
gst/gstpreset.c
View file

@ -45,7 +45,7 @@
* 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

2
gst/gstregistrybinary.c
View file

@ -302,7 +302,7 @@ gst_registry_binary_write_chunk (BinaryRegistryCache * cache,
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,

8
gst/gstregistrychunks.c
View file

@ -236,7 +236,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
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);
@ -296,7 +296,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
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);
@ -330,7 +330,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
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 =
@ -344,7 +344,7 @@ gst_registry_chunks_save_feature (GList ** list, GstPluginFeature * feature)
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);

4
gst/gstsegment.c
View file

@ -392,7 +392,7 @@ gst_segment_do_seek (GstSegment * segment, gdouble rate,
* 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.
@ -709,7 +709,7 @@ gst_segment_position_from_stream_time (const GstSegment * segment,
* 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.

2
gst/gststreams.c
View file

@ -237,7 +237,7 @@ gst_stream_set_stream_id (GstStream * stream, const gchar * stream_id)
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 =

4
gst/gsttaglist.c
View file

@ -614,7 +614,7 @@ gst_tag_get_nick (const gchar * tag)
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;
}
@ -1299,7 +1299,7 @@ gst_tag_list_add_valist (GstTagList * list, GstTagMergeMode mode,
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;
}

2
gst/gsttracerrecord.h
View file

@ -51,7 +51,7 @@ G_DEFINE_AUTOPTR_CLEANUP_FUNC(GstTracerRecord, gst_object_unref)
* @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

2
gst/gsttracerutils.c
View file

@ -27,7 +27,7 @@
* 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.
*/

2
gst/gsttypefindfactory.c
View file

@ -24,7 +24,7 @@
* @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>.

8
gst/gsturi.c
View file

@ -957,7 +957,7 @@ beach:
* @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.
*/
@ -2596,7 +2596,7 @@ gst_uri_get_query_table (const GstUri * uri)
* 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
*/
@ -2630,7 +2630,7 @@ gst_uri_set_query_table (GstUri * uri, GHashTable * query_table)
* 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
*/
@ -2805,7 +2805,7 @@ gst_uri_set_fragment (GstUri * uri, const gchar * fragment)
* 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

4
gst/gstutils.c
View file

@ -1984,7 +1984,7 @@ gst_element_link_pads_full (GstElement * src, const gchar * srcpadname,
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);
@ -2613,7 +2613,7 @@ gst_pad_get_parent_element (GstPad * pad)
* @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.
*/

2
gst/gstvalue.c
View file

@ -5495,7 +5495,7 @@ gst_value_list_equals_range (const GValue * list, const GValue * value)
}
/* "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)

2
gst/parse/grammar.y
View file

@ -845,7 +845,7 @@ elementary:
/*************************************************************
* 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

Some files were not shown because too many files have changed in this diff Show more