diff --git a/common b/common index 773e3a6496..79e6940e7f 160000 --- a/common +++ b/common @@ -1 +1 @@ -Subproject commit 773e3a64961084c37477faa464f12add3dfcd6dc +Subproject commit 79e6940e7ff1a6cbf959a1f7a0a3d1ed3f90d3ee diff --git a/docs/faq/Makefile.am b/docs/faq/Makefile.am index ea06c14609..0af304a08b 100644 --- a/docs/faq/Makefile.am +++ b/docs/faq/Makefile.am @@ -35,3 +35,7 @@ www-faq: gstreamer-faq perl -i -p -e's@href="index\.html@href="index.php@' $$a; \ perl -i -p -e's@href="(ar.*)\.html@href="$$1.php@' $$a; \ done + +check: + xmllint -noout -valid $(MAIN) + diff --git a/docs/faq/cvs.xml b/docs/faq/cvs.xml index 87e713f1a9..15dee4c1ef 100644 --- a/docs/faq/cvs.xml +++ b/docs/faq/cvs.xml @@ -30,15 +30,16 @@ prefix both aclocal and libtool are installed. You can do three things to fix this : -install automake in the same prefix as libtool -force use of the automake installed in the same prefix as libtool -by using the --with-automake option -figure out what prefix libtool has been installed to and point -aclocal to the right location by running +install automake in the same prefix as libtool +force use of the automake installed in the same prefix as libtool +by using the --with-automake option +figure out what prefix libtool has been installed to and point +aclocal to the right location by running export ACLOCAL_FLAGS="-I $(prefix)/share/aclocal" where you replace prefix with the prefix where libtool was installed. + diff --git a/docs/faq/developing.xml b/docs/faq/developing.xml index e3b4c291f3..459c613bc0 100644 --- a/docs/faq/developing.xml +++ b/docs/faq/developing.xml @@ -1,7 +1,7 @@ Developing applications with GStreamer - + diff --git a/docs/faq/general.xml b/docs/faq/general.xml index 4b832a3161..eec5e6b896 100644 --- a/docs/faq/general.xml +++ b/docs/faq/general.xml @@ -30,17 +30,17 @@ Why is GStreamer written in C ? Why not C++/Objective-C/... ? We like C. Aside from "personal preference", there are a number of technical reasons why C is nice in this project: -C is extremely portable. -C is fast. -It is easy to make language bindings for libraries written in C. - -The GObject object system provided by GLib implements objects in C, +C is extremely portable. +C is fast. +It is easy to make language bindings for libraries written in C. + +The GObject object system provided by GLib implements objects in C, in a portable, powerful way. This library provides for introspection and runtime dynamic typing. It is a full OO system, but without the syntactic sugar. If you want sugar, take a look at -GOB. -Use of C integrates nicely with Gtk+ and GNOME. Some people like -this a lot, but neither Gtk+ nor GNOME are required by GStreamer. +GOB. +Use of C integrates nicely with Gtk+ and GNOME. Some people like +this a lot, but neither Gtk+ nor GNOME are required by GStreamer. @@ -88,10 +88,10 @@ terms of the libraries we use. As a general rule, GStreamer aims at using only LGPL or BSD licensed libraries if available and only use GPL or proprietary libraries where no good LGPL or BSD alternatives are available. + From GStreamer 0.4.2 on, we implemented a license field for all of the plugins, and in the future we might have the application enforce a stricter policy (much like tainting in the kernel). - diff --git a/docs/faq/getting.xml b/docs/faq/getting.xml index 1ece463c3d..ca2cfbd211 100644 --- a/docs/faq/getting.xml +++ b/docs/faq/getting.xml @@ -11,12 +11,12 @@ Generally speaking, you have three options, ranging from easy to hard : - -distribution-specific packages - -source tarballs - -CVS + +distribution-specific packages + +source tarballs + +CVS diff --git a/docs/faq/start.xml b/docs/faq/start.xml index 74a97b683f..fa1d82c89b 100644 --- a/docs/faq/start.xml +++ b/docs/faq/start.xml @@ -3,18 +3,25 @@ So you're eager to get started learning about GStreamer. There's a few ways you can get started. - -If you want to learn by reading about it, start with - - + + + +If you want to learn by reading about it, start with + + + + + If you'd rather learn by trying it out, start with - - + + + + If you want to live on the bleeding edge and develop and use CVS, see - - + + + - diff --git a/docs/faq/troubleshooting.xml b/docs/faq/troubleshooting.xml index b2fbcdd5b4..d23df84e53 100644 --- a/docs/faq/troubleshooting.xml +++ b/docs/faq/troubleshooting.xml @@ -24,11 +24,11 @@ If you're not sure either way, then chances are good that you don't have it. You should get the plug-in and run gst-register to register it. How to get the plug-in depends on your distribution. -if you run GStreamer using packages for your distribution, you +if you run GStreamer using packages for your distribution, you should check what packages are available for your distribution and see if any of the available packages contains the plug-in. - -if you run GStreamer from a source install, there's a good chance + +if you run GStreamer from a source install, there's a good chance the plug-in didn't get built because you are missing an external library. When you ran configure, you should have gotten output of what plug-ins are going to be built. You can re-run configure to see if it's there. @@ -37,13 +37,13 @@ The most likely is that you're missing the library you need for it. Check the README file in gst-plugins to see what library you need. Make sure to remember to re-run configure after installing the supporting library ! - - + + if you run GStreamer from CVS, the same logic applies as for a source install. Go over the reasons why the plug-in didn't get configured for build. Check output of config.log for a clue as to why it doesn't get built if you're sure you have the library needed installed in a sane place. - + @@ -87,31 +87,31 @@ The second thing you can do is look at the backtrace to get an idea of where things are going wrong, or give us an idea of what is going wrong. To provide a backtrace, you should - + run the application in gdb by starting it with gdb (gst-application) (If the application is in a source tree instead of installed on the system, you might want to put "libtool" before "gdb") - - + + Pass on the command line arguments to the application by typing set args (the arguments to the application) at the (gdb) prompt - - + + Type "run" at the (gdb) prompt and wait for the application to segfault. The application will run a lot slower, however. - - + + After the segfault, type "bt" to get a backtrace. This is a stack of function calls detailing the path from main () to where the code is currently at. - - + + If the application you're trying to debug contains threads, it is also useful to do @@ -120,14 +120,12 @@ To provide a backtrace, you should and get backtraces of all of the threads involved, by switching to a different thread using "thread (number)" and then again requesting a backtrace using "bt". - - - + + If you can't or don't want to work out the problem yourself, a copy and paste of all this information should be included in your bug report. - - + diff --git a/docs/faq/using.xml b/docs/faq/using.xml index b04971e1e2..7abb18c12e 100644 --- a/docs/faq/using.xml +++ b/docs/faq/using.xml @@ -56,11 +56,11 @@ You can test this by trying to play a sine tone. For this, you need to connect the sinesrc plug-in to an output plug-in that matches your hardware. A (non-complete) list of output plug-ins for audio is -osssink for OSS output -esdsink for ESound output -artssink for aRTs output -alsasink for ALSA output -jacksink for JACK output +osssink for OSS output +esdsink for ESound output +artssink for aRTs output +alsasink for ALSA output +jacksink for JACK output First of all, run gst-inspect on the output plug-in you want to use to make sure you have it installed. For example, if you use OSS, run @@ -136,10 +136,10 @@ information, as we will most likely have to. When doing a bug report, you should at least describe -your distribution - -how you installed GStreamer (from cvs, source, packages, which ?) -if you installed GStreamer before +your distribution + +how you installed GStreamer (from cvs, source, packages, which ?) +if you installed GStreamer before