diff --git a/manual-autoplugging.md b/manual-autoplugging.md index 9ca597c793..f49c33cd01 100644 --- a/manual-autoplugging.md +++ b/manual-autoplugging.md @@ -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 [.. my_bus_callback goes here ..] diff --git a/manual-buffering.md b/manual-buffering.md index 7cbe823b09..f885c2946a 100644 --- a/manual-buffering.md +++ b/manual-buffering.md @@ -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 diff --git a/manual-bus.md b/manual-bus.md index 9768ce725d..215585d90c 100644 --- a/manual-bus.md +++ b/manual-bus.md @@ -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; [..] diff --git a/manual-compiling.md b/manual-compiling.md index 1cb0da7021..52e2b396a2 100644 --- a/manual-compiling.md +++ b/manual-compiling.md @@ -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. diff --git a/manual-data.md b/manual-data.md index 8ac19cc7c7..658979a7ba 100644 --- a/manual-data.md +++ b/manual-data.md @@ -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) diff --git a/manual-dataaccess.md b/manual-dataaccess.md index bd95730505..d9bd604cbe 100644 --- a/manual-dataaccess.md +++ b/manual-dataaccess.md @@ -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 @@ -281,7 +281,7 @@ sink before it goes to EOS. What follows is an example application that loosly follows this algorithm. -``` +``` c #include @@ -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 @@ -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 @@ -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 @@ -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 diff --git a/manual-dparams.md b/manual-dparams.md index b8d7407a03..4382d06982 100644 --- a/manual-dparams.md +++ b/manual-dparams.md @@ -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 #include @@ -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); diff --git a/manual-elements.md b/manual-elements.md index aaba96f9bf..e11f72d493 100644 --- a/manual-elements.md +++ b/manual-elements.md @@ -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 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 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 int @@ -264,7 +264,7 @@ and a whole lot more. `gst-inspect` will give a list of all factories, and `gst-inspect ` will list all of the above information, and a lot more. -``` +``` c #include int @@ -335,7 +335,7 @@ an Ogg/Vorbis player later in this manual. In code, the above graph is written like this: -``` +``` c #include int diff --git a/manual-helloworld.md b/manual-helloworld.md index a49bb6d6e7..f9e2d935f5 100644 --- a/manual-helloworld.md +++ b/manual-helloworld.md @@ -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 #include diff --git a/manual-init.md b/manual-init.md index aa97f9b86d..7aa55aa6ef 100644 --- a/manual-init.md +++ b/manual-init.md @@ -18,7 +18,7 @@ command line options. A typical program \[1\] would have code to initialize GStreamer that looks like this: -``` +``` c #include #include @@ -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 diff --git a/manual-intgration.md b/manual-intgration.md index c45c2d5b25..5812f85da5 100644 --- a/manual-intgration.md +++ b/manual-intgration.md @@ -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 #include - + 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 diff --git a/manual-metadata.md b/manual-metadata.md index e1844a30e3..946360edcc 100644 --- a/manual-metadata.md +++ b/manual-metadata.md @@ -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 diff --git a/manual-pads.md b/manual-pads.md index 321e664a9d..e4b49c9dc4 100644 --- a/manual-pads.md +++ b/manual-pads.md @@ -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 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 int diff --git a/manual-playback-components.md b/manual-playback-components.md index 76b4cbe9a2..840379475c 100644 --- a/manual-playback-components.md +++ b/manual-playback-components.md @@ -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 [.. 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 @@ -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 diff --git a/manual-programs.md b/manual-programs.md index 274f78d9e0..83fc7b951f 100644 --- a/manual-programs.md +++ b/manual-programs.md @@ -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 int diff --git a/manual-queryevents.md b/manual-queryevents.md index 125db4c90c..ce77dc7d37 100644 --- a/manual-queryevents.md +++ b/manual-queryevents.md @@ -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 @@ -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) diff --git a/manual-threads.md b/manual-threads.md index 819a13ac52..54cd7af6ce 100644 --- a/manual-threads.md +++ b/manual-threads.md @@ -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 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 diff --git a/pwg-advanced-events.md b/pwg-advanced-events.md index bff9ffa793..ea5666cc53 100644 --- a/pwg-advanced-events.md +++ b/pwg-advanced-events.md @@ -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) { diff --git a/pwg-advanced-interfaces.md b/pwg-advanced-interfaces.md index a68602b313..76711ba9d6 100644 --- a/pwg-advanced-interfaces.md +++ b/pwg-advanced-interfaces.md @@ -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) { diff --git a/pwg-advanced-qos.md b/pwg-advanced-qos.md index d14f3b74fa..963e138ca2 100644 --- a/pwg-advanced-qos.md +++ b/pwg-advanced-qos.md @@ -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 [...] diff --git a/pwg-advanced-request.md b/pwg-advanced-request.md index f4c7c8f555..d5781dd466 100644 --- a/pwg-advanced-request.md +++ b/pwg-advanced-request.md @@ -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, diff --git a/pwg-advanced-tagging.md b/pwg-advanced-tagging.md index 50cc559c14..6d9b03e30a 100644 --- a/pwg-advanced-tagging.md +++ b/pwg-advanced-tagging.md @@ -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) diff --git a/pwg-allocation.md b/pwg-allocation.md index 984be4e5c1..6ba5380570 100644 --- a/pwg-allocation.md +++ b/pwg-allocation.md @@ -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 @@ -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 @@ -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 @@ -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 #include diff --git a/pwg-building-args.md b/pwg-building-args.md index 970271541e..a92bed1775 100644 --- a/pwg-building-args.md +++ b/pwg-building-args.md @@ -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, diff --git a/pwg-building-boiler.md b/pwg-building-boiler.md index e3ee6b15bc..85186b5874 100644 --- a/pwg-building-boiler.md +++ b/pwg-building-boiler.md @@ -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 /* 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 diff --git a/pwg-building-chainfn.md b/pwg-building-chainfn.md index 178cd69444..9252aa53ab 100644 --- a/pwg-building-chainfn.md +++ b/pwg-building-chainfn.md @@ -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, diff --git a/pwg-building-eventfn.md b/pwg-building-eventfn.md index ca861efc0d..0060064540 100644 --- a/pwg-building-eventfn.md +++ b/pwg-building-eventfn.md @@ -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, diff --git a/pwg-building-pads.md b/pwg-building-pads.md index 2108854a31..df3096b80f 100644 --- a/pwg-building-pads.md +++ b/pwg-building-pads.md @@ -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 diff --git a/pwg-building-queryfn.md b/pwg-building-queryfn.md index 959f18be2c..41f1ea3127 100644 --- a/pwg-building-queryfn.md +++ b/pwg-building-queryfn.md @@ -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, diff --git a/pwg-building-testapp.md b/pwg-building-testapp.md index d83faf4049..12b08ebce7 100644 --- a/pwg-building-testapp.md +++ b/pwg-building-testapp.md @@ -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 static gboolean diff --git a/pwg-building-types.md b/pwg-building-types.md index 5f592989c6..9fbdbda958 100644 --- a/pwg-building-types.md +++ b/pwg-building-types.md @@ -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) diff --git a/pwg-checklist-element.md b/pwg-checklist-element.md index 50b803179a..df9bf915fe 100644 --- a/pwg-checklist-element.md +++ b/pwg-checklist-element.md @@ -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)); diff --git a/pwg-dparams.md b/pwg-dparams.md index e258b29395..61bfece96a 100644 --- a/pwg-dparams.md +++ b/pwg-dparams.md @@ -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 #include @@ -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); ``` diff --git a/pwg-negotiation.md b/pwg-negotiation.md index b193013930..19a5811932 100644 --- a/pwg-negotiation.md +++ b/pwg-negotiation.md @@ -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) diff --git a/pwg-other-base.md b/pwg-other-base.md index 262fad0744..bf3cf9ffdd 100644 --- a/pwg-other-base.md +++ b/pwg-other-base.md @@ -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); [..] diff --git a/pwg-scheduling.md b/pwg-scheduling.md index 52439c543b..ba7b9a23db 100644 --- a/pwg-scheduling.md +++ b/pwg-scheduling.md @@ -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 @@ -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