mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-31 11:32:38 +00:00
application-development: basics: fix missing markup
Additionally: a few minor formating fixes
This commit is contained in:
parent
42b41c32e3
commit
01102e37ca
6 changed files with 36 additions and 38 deletions
|
@ -44,7 +44,7 @@ take ownership of that element. If you destroy the bin, the element will
|
|||
be dereferenced with it. If you remove an element from a bin, it will be
|
||||
dereferenced automatically.
|
||||
|
||||
```
|
||||
```c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -89,7 +89,7 @@ The application programmer can create custom bins packed with elements
|
|||
to perform a specific task. This allows you, for example, to write an
|
||||
Ogg/Vorbis decoder with just the following lines of code:
|
||||
|
||||
```
|
||||
```c
|
||||
int
|
||||
main (int argc,
|
||||
char *argv[])
|
||||
|
@ -133,11 +133,11 @@ pipeline to start up the pipeline or shut it down.
|
|||
|
||||
The bin will perform the state changes on all its children from the sink
|
||||
element to the source element. This ensures that the downstream element
|
||||
is ready to receive data when the upstream element is brought to PAUSED
|
||||
or PLAYING. Similarly when shutting down, the sink elements will be set
|
||||
to READY or NULL first, which will cause the upstream elements to
|
||||
receive a FLUSHING error and stop the streaming threads before the
|
||||
elements are set to the READY or NULL state.
|
||||
is ready to receive data when the upstream element is brought to `PAUSED`
|
||||
or `PLAYING`. Similarly when shutting down, the sink elements will be set
|
||||
to `READY` or `NULL` first, which will cause the upstream elements to
|
||||
receive a `FLUSHING` error and stop the streaming threads before the
|
||||
elements are set to the `READY` or `NULL` state.
|
||||
|
||||
Note, however, that if elements are added to a bin or pipeline that's
|
||||
already running, , e.g. from within a "pad-added" signal callback, its
|
||||
|
|
|
@ -33,8 +33,8 @@ There are two different ways to use a bus:
|
|||
using `gst_bus_add_watch ()`. This handler will be called whenever
|
||||
the pipeline emits a message to the bus. In this handler, check the
|
||||
signal type (see next section) and do something accordingly. The
|
||||
return value of the handler should be TRUE to keep the handler
|
||||
attached to the bus, return FALSE to remove it.
|
||||
return value of the handler should be `TRUE` to keep the handler
|
||||
attached to the bus, return `FALSE` to remove it.
|
||||
|
||||
- Check for messages on the bus yourself. This can be done using
|
||||
`gst_bus_peek ()` and/or `gst_bus_poll ()`.
|
||||
|
@ -58,7 +58,7 @@ Note that if you're using the default GLib mainloop integration, you
|
|||
can, instead of attaching a watch, connect to the “message” signal on
|
||||
the bus. This way you don't have to `switch()` on all possible message
|
||||
types; just connect to the interesting signals in form of
|
||||
“message::\<type\>”, where \<type\> is a specific message type (see
|
||||
`message::<type>`, where `<type>` is a specific message type (see
|
||||
the next section for an explanation of message types).
|
||||
|
||||
The above snippet could then also be written as:
|
||||
|
|
|
@ -417,8 +417,8 @@ Those four states are:
|
|||
allowed to play the data which would make the clock run. In summary,
|
||||
PAUSED is the same as PLAYING but without a running clock.
|
||||
|
||||
Elements going into the PAUSED state should prepare themselves for
|
||||
moving over to the PLAYING state as soon as possible. Video or audio
|
||||
Elements going into the `PAUSED` state should prepare themselves for
|
||||
moving over to the `PLAYING` state as soon as possible. Video or audio
|
||||
outputs would, for example, wait for data to arrive and queue it so
|
||||
they can play it right after the state change. Also, video sinks can
|
||||
already play the first frame (since this does not affect the clock
|
||||
|
@ -427,14 +427,14 @@ Those four states are:
|
|||
filters, do not need to explicitly do anything in this state,
|
||||
however.
|
||||
|
||||
- `GST_STATE_PLAYING`: in the PLAYING state, an element does exactly
|
||||
the same as in the PAUSED state, except that the clock now runs.
|
||||
- `GST_STATE_PLAYING`: in the `PLAYING` state, an element does exactly
|
||||
the same as in the `PAUSED` state, except that the clock now runs.
|
||||
|
||||
You can change the state of an element using the function
|
||||
`gst_element_set_state ()`. If you set an element to another state,
|
||||
GStreamer will internally traverse all intermediate states. So if you
|
||||
set an element from NULL to PLAYING, GStreamer will internally set the
|
||||
element to READY and PAUSED in between.
|
||||
set an element from `NULL` to `PLAYING`, GStreamer will internally set the
|
||||
element to `READY` and `PAUSED` in between.
|
||||
|
||||
When moved to `GST_STATE_PLAYING`, pipelines will process data
|
||||
automatically. They do not need to be iterated in any form. Internally,
|
||||
|
|
|
@ -48,8 +48,8 @@ the pipeline bus so we can retrieve errors and detect the end-of-stream.
|
|||
|
||||
Let's now add all the code together to get our very first audio player:
|
||||
|
||||
``` c
|
||||
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
#include <glib.h>
|
||||
|
||||
|
@ -196,7 +196,6 @@ main (int argc,
|
|||
return 0;
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
We now have created a complete pipeline. We can visualise the pipeline
|
||||
|
@ -212,11 +211,14 @@ as follows:
|
|||
|
||||
## Compiling and Running helloworld.c
|
||||
|
||||
To compile the helloworld example, use: `gcc -Wall
|
||||
helloworld.c -o helloworld
|
||||
$(pkg-config --cflags --libs gstreamer-1.0)`. GStreamer makes use of
|
||||
`pkg-config` to get compiler and linker flags needed to compile this
|
||||
application.
|
||||
To compile the helloworld example, use:
|
||||
|
||||
```
|
||||
gcc -Wall helloworld.c -o helloworld $(pkg-config --cflags --libs gstreamer-1.0)
|
||||
```
|
||||
|
||||
GStreamer makes use of `pkg-config` to get compiler and linker
|
||||
flags needed to compile this application.
|
||||
|
||||
If you're running a non-standard installation (ie. you've installed
|
||||
GStreamer from source yourself instead of using pre-built packages),
|
||||
|
@ -225,9 +227,11 @@ correct location (`$libdir/pkgconfig`).
|
|||
|
||||
In the unlikely case that you are using an uninstalled GStreamer setup
|
||||
(ie. gst-uninstalled), you will need to use libtool to build the hello
|
||||
world program, like this: `libtool --mode=link gcc -Wall
|
||||
helloworld.c -o helloworld
|
||||
$(pkg-config --cflags --libs gstreamer-1.0)`.
|
||||
world program, like this:
|
||||
|
||||
```
|
||||
libtool --mode=link gcc -Wall helloworld.c -o helloworld $(pkg-config --cflags --libs gstreamer-1.0)
|
||||
```
|
||||
|
||||
You can run this example application with `./helloworld
|
||||
file.ogg`. Substitute `file.ogg` with your favourite Ogg/Vorbis file.
|
||||
|
|
|
@ -18,8 +18,8 @@ command line options.
|
|||
A typical program \[1\] would have code to initialize GStreamer that
|
||||
looks like this:
|
||||
|
||||
``` c
|
||||
|
||||
``` c
|
||||
#include <stdio.h>
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
@ -46,15 +46,13 @@ main (int argc,
|
|||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
Use the `GST_VERSION_MAJOR`, `GST_VERSION_MINOR` and `GST_VERSION_MICRO`
|
||||
macros to get the GStreamer version you are building against, or use the
|
||||
function `gst_version` to get the version your application is linked
|
||||
against. GStreamer currently uses a scheme where versions with the same
|
||||
major and minor versions are API-/ and ABI-compatible.
|
||||
major and minor versions are API- and ABI-compatible.
|
||||
|
||||
It is also possible to call the `gst_init` function with two `NULL`
|
||||
arguments, in which case no command line options will be parsed by
|
||||
|
@ -62,11 +60,11 @@ GStreamer.
|
|||
|
||||
## The GOption interface
|
||||
|
||||
You can also use a GOption table to initialize your own parameters as
|
||||
You can also use a `GOption` table to initialize your own parameters as
|
||||
shown in the next example:
|
||||
|
||||
``` c
|
||||
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -100,8 +98,6 @@ main (int argc,
|
|||
|
||||
return 0;
|
||||
}
|
||||
|
||||
|
||||
```
|
||||
|
||||
As shown in this fragment, you can use a
|
||||
|
|
|
@ -179,7 +179,6 @@ the audio samplerate and the amount of channels, plus some more that you
|
|||
don't need to worry about for now.
|
||||
|
||||
```
|
||||
|
||||
Pad Templates:
|
||||
SRC template: 'src'
|
||||
Availability: Always
|
||||
|
@ -193,7 +192,6 @@ Pad Templates:
|
|||
Availability: Always
|
||||
Capabilities:
|
||||
audio/x-vorbis
|
||||
|
||||
```
|
||||
|
||||
### Properties and values
|
||||
|
@ -209,8 +207,8 @@ possible value types that can be used:
|
|||
- An integer value (`G_TYPE_INT`): the property has this exact
|
||||
value.
|
||||
|
||||
- A boolean value (`G_TYPE_BOOLEAN`): the property is either TRUE
|
||||
or FALSE.
|
||||
- A boolean value (`G_TYPE_BOOLEAN`): the property is either `TRUE`
|
||||
or `FALSE`.
|
||||
|
||||
- A float value (`G_TYPE_FLOAT`): the property has this exact
|
||||
floating point value.
|
||||
|
|
Loading…
Reference in a new issue