mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-23 02:01:12 +00:00
Add missing language tags to code blocks
This commit is contained in:
parent
43a2465744
commit
80096e588a
36 changed files with 108 additions and 112 deletions
|
@ -97,7 +97,7 @@ will print the detected media type, or tell that the media type was not
|
|||
found. The next section will introduce more useful behaviours, such as
|
||||
plugging together a decoding pipeline.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
[.. my_bus_callback goes here ..]
|
||||
|
|
|
@ -39,7 +39,7 @@ What follows is an example of how the message handler could deal with
|
|||
the BUFFERING messages. We will see more advanced methods in [Buffering
|
||||
strategies](#buffering-strategies).
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -225,7 +225,7 @@ buffering](#download-buffering)).
|
|||
|
||||
This is what the code would look like:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
|
|
@ -63,7 +63,7 @@ the next section for an explanation of message types).
|
|||
|
||||
The above snippet could then also be written as:
|
||||
|
||||
```
|
||||
``` c
|
||||
GstBus *bus;
|
||||
|
||||
[..]
|
||||
|
|
|
@ -30,7 +30,7 @@ be dynamically loadable libraries. In the example below, you would be
|
|||
able to call `gst_element_factory_make
|
||||
("my-element-name", "some-name")` to create an instance of the element.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
/*
|
||||
* Here, you would write the actual plugin code.
|
||||
|
|
|
@ -58,7 +58,7 @@ to get a more complete picture of the data concept.
|
|||
Since most applications seek in time units, our example below does so
|
||||
too:
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
seek_to_time (GstElement *element,
|
||||
guint64 time_ns)
|
||||
|
|
|
@ -115,7 +115,7 @@ In any case, most common buffer operations that elements can do in
|
|||
`_chain ()` functions, can be done in probe callbacks as well. The
|
||||
example below gives a short impression on how to use them.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
@ -281,7 +281,7 @@ sink before it goes to EOS.
|
|||
What follows is an example application that loosly follows this
|
||||
algorithm.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
@ -620,7 +620,7 @@ on the outgoing buffers in such a way that we play 2 frames per second.
|
|||
Note how we use the pull mode method of pushing new buffers into appsrc
|
||||
although appsrc is running in push mode.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
@ -766,7 +766,7 @@ Consider configuring the following properties in the appsink:
|
|||
What follows is an example on how to capture a snapshot of a video
|
||||
stream using appsink.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
@ -937,7 +937,7 @@ caps on the source pad.
|
|||
Below is an example of how you can change the caps of a pipeline while
|
||||
in the PLAYING state:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <stdlib.h>
|
||||
|
@ -1181,7 +1181,7 @@ be used in the PAUSED state as well.
|
|||
Let show you how this works with an example. This example changes the
|
||||
video effect on a simple pipeline every second.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
|
|
@ -26,7 +26,7 @@ in the core library. The existing implementations are contained within
|
|||
the `gstcontroller` library. You need to include the header in your
|
||||
application's source file:
|
||||
|
||||
```
|
||||
``` c
|
||||
...
|
||||
#include <gst/gst.h>
|
||||
#include <gst/controller/gstinterpolationcontrolsource.h>
|
||||
|
@ -45,7 +45,7 @@ If we have our pipeline set up and want to control some parameters, we
|
|||
first need to create a control-source. Lets use an interpolation
|
||||
control-source:
|
||||
|
||||
```
|
||||
``` c
|
||||
csource = gst_interpolation_control_source_new ();
|
||||
g_object_set (csource, "mode", GST_INTERPOLATION_MODE_LINEAR, NULL);
|
||||
|
||||
|
@ -56,7 +56,7 @@ is done with a control-binding. One control source can be attached to
|
|||
several object properties (even in different objects) using separate
|
||||
control-bindings.
|
||||
|
||||
```
|
||||
``` c
|
||||
gst_object_add_control_binding (object, gst_direct_control_binding_new (object, "prop1", csource));
|
||||
|
||||
```
|
||||
|
@ -77,7 +77,7 @@ in the list. If e.g. the pipeline runs a loop (using a segmented seek),
|
|||
the control-curve gets repeated as
|
||||
well.
|
||||
|
||||
```
|
||||
``` c
|
||||
GstTimedValueControlSource *tv_csource = (GstTimedValueControlSource *)csource;
|
||||
gst_timed_value_control_source_set (tv_csource, 0 * GST_SECOND, 0.0);
|
||||
gst_timed_value_control_source_set (tv_csource, 1 * GST_SECOND, 1.0);
|
||||
|
|
|
@ -101,7 +101,7 @@ The following example \[1\] shows how to create an element named
|
|||
*source* from the element factory named *fakesrc*. It checks if the
|
||||
creation succeeded. After checking, it unrefs the element.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -143,7 +143,7 @@ create the *fakesrc* element, a fake data source. The function
|
|||
()`](http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/gstreamer/html/GstElementFactory.html#gst-element-factory-create)
|
||||
will use the element factory to create an element with the given name.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -190,7 +190,7 @@ functions `gst_element_factory_make ()` or `gst_element_factory_create
|
|||
`gst_object_set_name` and `gst_object_get_name` or use the `GObject`
|
||||
property mechanism as shown below.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -264,7 +264,7 @@ and a whole lot more. `gst-inspect` will give a list of all factories,
|
|||
and `gst-inspect <factory-name>` will list all of the above information,
|
||||
and a lot more.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
@ -335,7 +335,7 @@ an Ogg/Vorbis player later in this manual.
|
|||
|
||||
In code, the above graph is written like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
|
|
@ -49,7 +49,7 @@ and detect the end-of-stream.
|
|||
|
||||
Let's now add all the code together to get our very first audio player:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/gst.h>
|
||||
#include <glib.h>
|
||||
|
|
|
@ -18,7 +18,7 @@ command line options.
|
|||
A typical program \[1\] would have code to initialize GStreamer that
|
||||
looks like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <stdio.h>
|
||||
#include <gst/gst.h>
|
||||
|
@ -65,7 +65,7 @@ GStreamer.
|
|||
You can also use a GOption table to initialize your own parameters as
|
||||
shown in the next example:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
|
|
@ -50,50 +50,50 @@ integrate as closely as possible with the GNOME desktop:
|
|||
can be passed to `gnome_program_init ()`. The following example
|
||||
requires GTK 2.6 or newer (previous GTK versions do not support
|
||||
command line parsing via GOption yet)
|
||||
|
||||
```
|
||||
|
||||
``` c
|
||||
#include <gtk/gtk.h>
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
||||
static gchar **cmd_filenames = NULL;
|
||||
|
||||
|
||||
static GOptionEntries cmd_options[] = {
|
||||
/* here you can add command line options for your application. Check
|
||||
* the GOption section in the GLib API reference for a more elaborate
|
||||
* example of how to add your own command line options here */
|
||||
|
||||
|
||||
/* at the end we have a special option that collects all remaining
|
||||
* command line arguments (like filenames) for us. If you don't
|
||||
* need this, you can safely remove it */
|
||||
{ G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_FILENAME_ARRAY, &cmd_filenames,
|
||||
"Special option that collects any remaining arguments for us" },
|
||||
|
||||
|
||||
/* mark the end of the options array with a NULL option */
|
||||
{ NULL, }
|
||||
};
|
||||
|
||||
|
||||
/* this should usually be defined in your config.h */
|
||||
#define VERSION "0.0.1"
|
||||
|
||||
|
||||
gint
|
||||
main (gint argc, gchar **argv)
|
||||
{
|
||||
GOptionContext *context;
|
||||
GOptionGroup *gstreamer_group, *gtk_group;
|
||||
GError *err = NULL;
|
||||
|
||||
|
||||
context = g_option_context_new ("gtk-demo-app");
|
||||
|
||||
|
||||
/* get command line options from GStreamer and add them to the group */
|
||||
gstreamer_group = gst_init_get_option_group ();
|
||||
g_option_context_add_group (context, gstreamer_group);
|
||||
gtk_group = gtk_get_option_group (TRUE);
|
||||
g_option_context_add_group (context, gtk_group);
|
||||
|
||||
|
||||
/* add our own options. If you are using gettext for translation of your
|
||||
* strings, use GETTEXT_PACKAGE here instead of NULL */
|
||||
g_option_context_add_main_entries (context, cmd_options, NULL);
|
||||
|
||||
|
||||
/* now parse the commandline options, note that this already
|
||||
* calls gtk_init() and gst_init() */
|
||||
if (!g_option_context_parse (ctx, &argc, &argv, &err)) {
|
||||
|
@ -103,25 +103,24 @@ integrate as closely as possible with the GNOME desktop:
|
|||
exit (1);
|
||||
}
|
||||
g_option_context_free (ctx);
|
||||
|
||||
|
||||
/* any filenames we got passed on the command line? parse them! */
|
||||
if (cmd_filenames != NULL) {
|
||||
guint i, num;
|
||||
|
||||
|
||||
num = g_strv_length (cmd_filenames);
|
||||
for (i = 0; i < num; ++i) {
|
||||
/* do something with the filename ... */
|
||||
g_print ("Adding to play queue: %s\n", cmd_filenames[i]);
|
||||
}
|
||||
|
||||
|
||||
g_strfreev (cmd_filenames);
|
||||
cmd_filenames = NULL;
|
||||
}
|
||||
|
||||
|
||||
[..]
|
||||
|
||||
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
- GNOME uses Pulseaudio for audio, use the pulsesrc and pulsesink
|
||||
|
|
|
@ -38,7 +38,7 @@ display.
|
|||
|
||||
The following example will extract tags from a file and print them:
|
||||
|
||||
```
|
||||
``` c
|
||||
/* compile with:
|
||||
* gcc -o tags tags.c `pkg-config --cflags --libs gstreamer-1.0` */
|
||||
#include <gst/gst.h>
|
||||
|
|
|
@ -49,7 +49,7 @@ to inform you when the element has created a new pad from one of its
|
|||
“sometimes” pad templates. The following piece of code is an example
|
||||
of how to do this:
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
static void
|
||||
|
@ -325,7 +325,7 @@ types of caps are *ANY caps* and *empty caps*.
|
|||
Here is an example of how to extract the width and height from a set of
|
||||
fixed video caps:
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
read_video_props (GstCaps *caps)
|
||||
{
|
||||
|
@ -359,7 +359,7 @@ do this using a `capsfilter` element in your pipeline. In order to do
|
|||
this, you also need to create your own `GstCaps`. The easiest way to do
|
||||
this is by using the convenience function `gst_caps_new_simple ()`:
|
||||
|
||||
```
|
||||
``` c
|
||||
static gboolean
|
||||
link_elements_with_filter (GstElement *element1, GstElement *element2)
|
||||
{
|
||||
|
@ -399,7 +399,7 @@ In some cases, you will want to create a more elaborate set of
|
|||
capabilities to filter a link between two pads. Then, this function is
|
||||
too simplistic and you'll want to use the method `gst_caps_new_full ()`:
|
||||
|
||||
```
|
||||
``` c
|
||||
static gboolean
|
||||
link_elements_with_filter (GstElement *element1, GstElement *element2)
|
||||
{
|
||||
|
@ -464,7 +464,7 @@ like ordinary pads.
|
|||
|
||||
A ghostpad is created using the function `gst_ghost_pad_new ()`:
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
|
|
@ -38,7 +38,7 @@ e.g. file:///tmp/my.ogg or http://www.example.org/stream.ogg).
|
|||
Internally, playbin will set up a pipeline to playback the media
|
||||
location.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
[.. my_bus_callback goes here ..]
|
||||
|
@ -121,7 +121,7 @@ about the newly found decoded stream. For unknown streams (which might
|
|||
be the whole stream), it will emit the “unknown-type” signal. The
|
||||
application is then responsible for reporting the error to the user.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
@ -305,7 +305,7 @@ element to decode into raw audio and video streams which we then link to
|
|||
the playsink request pads. We only link the first audio and video pads,
|
||||
you could use an input-selector to link all pads.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
|
|
@ -30,7 +30,7 @@ function gst\_parse\_launch () that you can use to construct a pipeline.
|
|||
The following program lets you create an MP3 pipeline using the
|
||||
gst\_parse\_launch () function:
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
int
|
||||
|
|
|
@ -32,7 +32,7 @@ backwards until one element can handle it; that result will be sent back
|
|||
to the function caller. Usually, that is the demuxer, although with live
|
||||
sources (from a webcam), it is the source itself.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
@ -91,7 +91,7 @@ fine to just specify GST\_SEEK\_TYPE\_NONE and -1 as end\_method and end
|
|||
offset. The behaviour of a seek is also wrapped in the `gst_element_seek
|
||||
()`.
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
seek_to_time (GstElement *pipeline,
|
||||
gint64 time_nanoseconds)
|
||||
|
|
|
@ -97,12 +97,7 @@ configure on the task. Below is the implementation of a `GstTaskPool`
|
|||
subclass that uses pthreads to create a SCHED\_RR real-time thread. Note
|
||||
that creating real-time threads might require extra priveleges.
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
``` c
|
||||
#include <pthread.h>
|
||||
|
||||
typedef struct
|
||||
|
@ -210,7 +205,7 @@ In a next step we need to actually configure the custom taskpool when
|
|||
the fakesrc needs it. For this we intercept the STREAM\_STATUS messages
|
||||
with a sync handler.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
static GMainLoop* loop;
|
||||
|
@ -328,7 +323,7 @@ main (int argc, char *argv[])
|
|||
|
||||
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
Note that this program likely needs root permissions in order to create
|
||||
real-time threads. When the thread can't be created, the state change
|
||||
|
|
|
@ -25,7 +25,7 @@ processed or queued in the pipeline). The most common downstream events
|
|||
|
||||
Here is a typical event function:
|
||||
|
||||
```
|
||||
``` c
|
||||
static gboolean
|
||||
gst_my_filter_sink_event (GstPad *pad, GstObject * parent, GstEvent * event)
|
||||
{
|
||||
|
|
|
@ -55,7 +55,7 @@ for the interface that you're wanting to support. The example below
|
|||
explains how to add support for a simple interface with no further
|
||||
dependencies.
|
||||
|
||||
```
|
||||
``` c
|
||||
static void gst_my_filter_some_interface_init (GstSomeInterface *iface);
|
||||
|
||||
GType
|
||||
|
@ -104,7 +104,7 @@ gst_my_filter_some_interface_init (GstSomeInterface *iface)
|
|||
Or more
|
||||
conveniently:
|
||||
|
||||
```
|
||||
``` c
|
||||
static void gst_my_filter_some_interface_init (GstSomeInterface *iface);
|
||||
|
||||
G_DEFINE_TYPE_WITH_CODE (GstMyFilter, gst_my_filter,GST_TYPE_ELEMENT,
|
||||
|
@ -158,7 +158,7 @@ plugin implementing this interface has to handle all cases. There are
|
|||
only 2 methods that plugins writers have to implement and they most
|
||||
probably look like that :
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
gst_my_filter_set_window_handle (GstVideoOverlay *overlay, guintptr handle)
|
||||
{
|
||||
|
@ -182,7 +182,7 @@ You will also need to use the interface methods to post messages when
|
|||
needed such as when receiving a CAPS event where you will know the video
|
||||
geometry and maybe create the window.
|
||||
|
||||
```
|
||||
``` c
|
||||
static MyFilterWindow *
|
||||
gst_my_filter_window_create (GstMyFilter *my_filter, gint width, gint height)
|
||||
{
|
||||
|
|
|
@ -71,7 +71,7 @@ value of the QOS event and use them in the data processing function. The
|
|||
element will need to use a lock to protect these QoS values as shown in
|
||||
the example below. Also make sure to pass the QoS event upstream.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -115,7 +115,7 @@ timestamp as: timestamp + 2 \* jitter + duration.
|
|||
|
||||
A possible algorithm typically looks like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ the number of the source pad over which the data should be sent.
|
|||
The code to parse this file and create the dynamic “sometimes” pads,
|
||||
looks like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
typedef struct _GstMyFilter {
|
||||
[..]
|
||||
|
@ -216,7 +216,7 @@ GST\_PAD\_REQUEST presence and implement the `request_new_pad` virtual
|
|||
method in `GstElement`. To clean up, you will need to implement the
|
||||
`release_pad` virtual method.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static GstPad * gst_my_filter_request_new_pad (GstElement *element,
|
||||
GstPadTemplate *templ,
|
||||
|
|
|
@ -71,7 +71,7 @@ a good idea to add it to `gsttag.c` instead. That's up to you to decide.
|
|||
If you want to do it in your own element, it's easiest to register the
|
||||
tag in one of your class init functions, preferably `_class_init ()`.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static void
|
||||
gst_my_filter_class_init (GstMyFilterClass *klass)
|
||||
|
@ -111,7 +111,7 @@ incoming events.
|
|||
Warning, this example is outdated and doesn't work with the 1.0 version
|
||||
of GStreamer anymore.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
GType
|
||||
gst_my_filter_get_type (void)
|
||||
|
|
|
@ -57,7 +57,7 @@ accessed according to the requested access mode.
|
|||
Below is an example of making a `GstMemory` object and using the
|
||||
`gst_memory_map()` to access the memory region.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -135,7 +135,7 @@ pointer to this block.
|
|||
|
||||
Below is an example of how to create a buffer and access its memory.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
GstBuffer *buffer;
|
||||
|
@ -195,7 +195,7 @@ to configure the metadata structure for you.
|
|||
Let's have a look at the metadata that is used to specify a cropping
|
||||
region for video frames.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/video/gstvideometa.h>
|
||||
|
||||
|
@ -218,7 +218,7 @@ region for video frames.
|
|||
An element can then use the metadata on the buffer when rendering the
|
||||
frame like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/video/gstvideometa.h>
|
||||
|
||||
|
@ -261,7 +261,7 @@ this step and move on to the implementation step.
|
|||
First we start with making the `my-example-meta.h` header file that will
|
||||
contain the definition of the API and structure for our metadata.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/gst.h>
|
||||
|
||||
|
@ -295,7 +295,7 @@ metadata with our new API.
|
|||
Next let's have a look at how the `my_example_meta_api_get_type ()`
|
||||
function is implemented in the `my-example-meta.c` file.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include "my-example-meta.h"
|
||||
|
||||
|
@ -329,7 +329,7 @@ convenience `MY_EXAMPLE_META_INFO` macro. You will also make a method to
|
|||
add your metadata implementation to a `GstBuffer`. Your
|
||||
`my-example-meta.h` header file will need these additions:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -347,7 +347,7 @@ MyExampleMeta * gst_buffer_add_my_example_meta (GstBuffer *buffer,
|
|||
Let's have a look at how these functions are implemented in the
|
||||
`my-example-meta.c` file.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -466,7 +466,7 @@ configure it. Trying to configure a bufferpool that is not in the
|
|||
inactive state will fail. Likewise, trying to activate a bufferpool that
|
||||
is not configured will fail.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
GstStructure *config;
|
||||
|
||||
|
@ -526,7 +526,7 @@ activated with `gst_buffer_pool_set_active (pool, TRUE)`. From that
|
|||
point on you can use `gst_buffer_pool_acquire_buffer ()` to retrieve a
|
||||
buffer from the pool, like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -593,7 +593,7 @@ buffers.
|
|||
|
||||
Below is an example of the ALLOCATION query.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
#include <gst/video/video.h>
|
||||
#include <gst/video/gstvideometa.h>
|
||||
|
|
|
@ -18,7 +18,7 @@ set functions. Note that `GObject` will not automatically set your
|
|||
instance variable to the default value, you will have to do that in the
|
||||
`_init ()` function of your element.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
/* properties */
|
||||
enum {
|
||||
|
@ -105,7 +105,7 @@ we'll give a short example of where this is useful. Note that using
|
|||
integers here would probably completely confuse the user, because they
|
||||
make no sense in this context. The example is stolen from videotestsrc.
|
||||
|
||||
```
|
||||
``` c
|
||||
typedef enum {
|
||||
GST_VIDEOTESTSRC_SMPTE,
|
||||
GST_VIDEOTESTSRC_SNOW,
|
||||
|
|
|
@ -123,7 +123,7 @@ file (although since the interface to the code is entirely defined by
|
|||
the plugin system, and doesn't depend on reading a header file, this is
|
||||
not crucial.)
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
/* Definition of structure storing data for this element. */
|
||||
|
@ -163,7 +163,7 @@ Using this header file, you can use the following macro to setup the
|
|||
`GObject` basics in your source file so that all functions will be
|
||||
called appropriately:
|
||||
|
||||
```
|
||||
``` c
|
||||
#include "filter.h"
|
||||
|
||||
G_DEFINE_TYPE (GstMyFilter, gst_my_filter, GST_TYPE_ELEMENT);
|
||||
|
@ -189,7 +189,7 @@ parameters:
|
|||
|
||||
For example:
|
||||
|
||||
```
|
||||
``` c
|
||||
gst_element_class_set_static_metadata (klass,
|
||||
"An example plugin",
|
||||
"Example/FirstExample",
|
||||
|
@ -203,7 +203,7 @@ The element details are registered with the plugin during the
|
|||
`_class_init ()` function should be set for this GObject in the function
|
||||
where you register the type with GLib.
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
gst_my_filter_class_init (GstMyFilterClass * klass)
|
||||
{
|
||||
|
@ -237,7 +237,7 @@ A GstStaticPadTemplate is a description of a pad that the element will
|
|||
|
||||
For example:
|
||||
|
||||
```
|
||||
``` c
|
||||
static GstStaticPadTemplate sink_factory =
|
||||
GST_STATIC_PAD_TEMPLATE (
|
||||
"sink",
|
||||
|
@ -287,7 +287,7 @@ supported values. In case of an audio filter that supports raw integer
|
|||
16-bit audio, mono or stereo at any samplerate, the correct template
|
||||
would look like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static GstStaticPadTemplate sink_factory =
|
||||
GST_STATIC_PAD_TEMPLATE (
|
||||
|
@ -329,7 +329,7 @@ FALSE depending on whether it loaded initialized any dependencies
|
|||
correctly. Also, in this function, any supported element type in the
|
||||
plugin should be registered.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
static gboolean
|
||||
|
|
|
@ -9,7 +9,7 @@ place. In the case of a simple filter, `_chain ()` functions are mostly
|
|||
linear functions - so for each incoming buffer, one buffer will go out,
|
||||
too. Below is a very simple implementation of a chain function:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static GstFlowReturn gst_my_filter_chain (GstPad *pad,
|
||||
GstObject *parent,
|
||||
|
|
|
@ -12,7 +12,7 @@ pads as well as source pads.
|
|||
Below follows a very simple event function that we install on the sink
|
||||
pad of our element.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static gboolean gst_my_filter_sink_event (GstPad *pad,
|
||||
GstObject *parent,
|
||||
|
|
|
@ -23,7 +23,7 @@ operate in looping mode, which means that they can pull data themselves.
|
|||
More on this topic later. After that, you have to register the pad with
|
||||
the element. This happens like this:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ on sink pads as well as source pads.
|
|||
Below follows a very simple query function that we install on the source
|
||||
pad of our element.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static gboolean gst_my_filter_src_query (GstPad *pad,
|
||||
GstObject *parent,
|
||||
|
|
|
@ -55,7 +55,7 @@ memory and caches. Also, it should close down any references held to
|
|||
possible support libraries. Your application should `unref ()` the
|
||||
pipeline and make sure it doesn't crash.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include <gst/gst.h>
|
||||
|
||||
static gboolean
|
||||
|
|
|
@ -81,7 +81,7 @@ be loaded in order to detect a stream's type. Below is an example that
|
|||
will recognize AVI files, which start with a “RIFF” tag, then the size
|
||||
of the file and then an “AVI” tag:
|
||||
|
||||
```
|
||||
``` c
|
||||
static void
|
||||
gst_my_typefind_function (GstTypeFind *tf,
|
||||
gpointer data)
|
||||
|
|
|
@ -44,7 +44,7 @@ we will try to explain why those requirements are set.
|
|||
- Ideally, elements should use their own debugging category. Most
|
||||
elements use the following code to do that:
|
||||
|
||||
```
|
||||
``` c
|
||||
GST_DEBUG_CATEGORY_STATIC (myelement_debug);
|
||||
#define GST_CAT_DEFAULT myelement_debug
|
||||
|
||||
|
@ -66,7 +66,7 @@ we will try to explain why those requirements are set.
|
|||
- Elements should use GST\_DEBUG\_FUNCPTR when setting pad functions
|
||||
or overriding element class methods, for example:
|
||||
|
||||
```
|
||||
``` c
|
||||
gst_pad_set_event_func (myelement->srcpad,
|
||||
GST_DEBUG_FUNCPTR (my_element_src_event));
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ property values over time.
|
|||
The controller subsystem is contained within the `gstcontroller`
|
||||
library. You need to include the header in your element's source file:
|
||||
|
||||
```
|
||||
``` c
|
||||
...
|
||||
#include <gst/gst.h>
|
||||
#include <gst/controller/gstcontroller.h>
|
||||
|
@ -29,7 +29,7 @@ Even though the `gstcontroller` library may be linked into the host
|
|||
application, you should make sure it is initialized in your
|
||||
`plugin_init` function:
|
||||
|
||||
```
|
||||
``` c
|
||||
static gboolean
|
||||
plugin_init (GstPlugin *plugin)
|
||||
{
|
||||
|
@ -46,7 +46,7 @@ Therefore the next step is to mark controllable parameters. This is done
|
|||
by using the special flag `GST_PARAM_CONTROLLABLE`. when setting up
|
||||
GObject params in the `_class_init` method.
|
||||
|
||||
```
|
||||
``` c
|
||||
g_object_class_install_property (gobject_class, PROP_FREQ,
|
||||
g_param_spec_double ("freq", "Frequency", "Frequency of test signal",
|
||||
0.0, 20000.0, 440.0,
|
||||
|
@ -62,7 +62,7 @@ for these parameters. The approach the controller subsystem takes is to
|
|||
make plugins responsible for pulling the changes in. This requires just
|
||||
one action:
|
||||
|
||||
```
|
||||
``` c
|
||||
gst_object_sync_values(element,timestamp);
|
||||
|
||||
```
|
||||
|
|
|
@ -92,7 +92,7 @@ the caps presented in the padtemplate. As soon as the pad is negotiated,
|
|||
the CAPS query will return the negotiated caps (and nothing else). These
|
||||
are the relevant code snippets for fixed caps source pads.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[..]
|
||||
pad = gst_pad_new_from_static_template (..);
|
||||
|
@ -105,7 +105,7 @@ are the relevant code snippets for fixed caps source pads.
|
|||
The fixed caps can then be set on the pad by calling `gst_pad_set_caps
|
||||
()`.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[..]
|
||||
caps = gst_caps_new_simple ("audio/x-raw",
|
||||
|
@ -162,7 +162,7 @@ Below is an example of a negotiation steps of a typical transform
|
|||
element. In the sink pad CAPS event handler, we compute the caps for the
|
||||
source pad and set those.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
[...]
|
||||
|
||||
|
@ -265,7 +265,7 @@ Let's look at the example of an element that can convert between
|
|||
samplerates, so where input and output samplerate don't have to be the
|
||||
same:
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static gboolean
|
||||
gst_my_filter_setcaps (GstMyFilter *filter,
|
||||
|
@ -402,7 +402,7 @@ that this elements supports, taking into account limitations of peer
|
|||
elements further downstream or upstream, sorted by order of preference,
|
||||
highest preference first.
|
||||
|
||||
```
|
||||
``` c
|
||||
|
||||
static gboolean
|
||||
gst_my_filter_query (GstPad *pad, GstObject * parent, GstQuery * query)
|
||||
|
|
|
@ -44,7 +44,7 @@ though:
|
|||
Sink elements can derive from `GstBaseSink` using the usual `GObject`
|
||||
convenience macro `G_DEFINE_TYPE ()`:
|
||||
|
||||
```
|
||||
``` c
|
||||
G_DEFINE_TYPE (GstMySink, gst_my_sink, GST_TYPE_BASE_SINK);
|
||||
|
||||
[..]
|
||||
|
|
|
@ -111,7 +111,7 @@ element(s) support pull-mode scheduling. If that is possible, you can
|
|||
activate the sinkpad in pull-mode. Inside the activate\_mode function
|
||||
you can then start the task.
|
||||
|
||||
```
|
||||
``` c
|
||||
#include "filter.h"
|
||||
#include <string.h>
|
||||
|
||||
|
@ -213,6 +213,7 @@ over its source pad. It's not all that useful, but provides some more
|
|||
flexibility than the old push-mode case that we've been looking at so
|
||||
far.
|
||||
|
||||
``` c
|
||||
#define BLOCKSIZE 2048
|
||||
|
||||
static void
|
||||
|
@ -261,6 +262,7 @@ far.
|
|||
GST_DEBUG_OBJECT (filter, "pausing task");
|
||||
gst_pad_pause_task (filter->sinkpad);
|
||||
}
|
||||
```
|
||||
|
||||
# Providing random access
|
||||
|
||||
|
|
Loading…
Reference in a new issue