Commit 4a402c1c authored by luz.paz's avatar luz.paz Committed by Tim-Philipp Müller

Fix typos in comments and docs

Found via `codespell`

https://bugzilla.gnome.org/show_bug.cgi?id=795610
parent bad751b2
......@@ -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
......
......@@ -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" />
......
......@@ -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)
......
......@@ -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
......
......@@ -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.
......
......@@ -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.
......
......@@ -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
......
......@@ -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,
......
......@@ -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);
......
......@@ -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.
......@@ -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
......
......@@ -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.
......
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.
......
......@@ -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.
......
......@@ -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
......
......@@ -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 ==
......
......@@ -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
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
......
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
......
......@@ -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
......
......@@ -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)
......
......@@ -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
......
......@@ -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,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:
......
......@@ -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
......
......@@ -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
......
......@@ -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.
......@@ -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.
......
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)
......
......@@ -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.
......
......@@ -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
......
......@@ -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.
......
......@@ -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:
......
......@@ -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
......
......@@ -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
......
......@@ -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)
......
......@@ -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.
......
......@@ -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.