validate:docs: fix spelling mistakes

https://bugzilla.gnome.org/show_bug.cgi?id=736160
This commit is contained in:
Felix Schwarz 2014-09-05 19:47:00 +00:00 committed by Thibault Saunier
parent 3755581fd3
commit 1a8b460d23
5 changed files with 26 additions and 26 deletions

View file

@ -28,7 +28,7 @@ this helps tracking down the problem and fixing it.
= Runner
The GstValidateRunner is the point of communication for the app to gst-validate
monitoring. It provides an API to gather reports and to make them acessible
monitoring. It provides an API to gather reports and to make them accessible
to the application.
== Reporter types

View file

@ -7,7 +7,7 @@ directly with the path tools/<tool-executable>
1- gst-validate-1.0: It is the simplest tool and is used to run a gst
launch style pipeline. Monitors are added to it to identify issues in the
used elements. At the end a report will be printed, this report will
contain informations about all issues that were encontered while running
contain information about all issues that were encountered while running
gst-validate. To view issues as they are created, set the environment
variable GST_DEBUG=validate:2 and it will be printed as gstreamer
debugging. You can basically run any GstPipeline pipeline using it.
@ -39,7 +39,7 @@ source scenario files in validate/data/
You can find more information about scenarios on the GstValidateScenario documentation: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-validate/html/GstValidateScenario.html
You can find more information about the various action types avalaible to be executed with:
You can find more information about the various action types available to be executed with:
gst-validate-1.0 -t <optional-action-type>
@ -50,7 +50,7 @@ or:
2- gst-validate-transcoding-1.0: Transcodes input-uri to output-uri,
using the given encoding profile. The pipeline will be monitored for
possible issues detection using the gst-validate lib, at the end of
execution, a report containing informations about all found issues will
execution, a report containing information about all found issues will
be printed.
Example:
@ -62,12 +62,12 @@ Example:
The same scenarios can be activated on gst-validate-transcoding-1.0 as
with gst-validate-1.0
3- gst-validate-media-check-1.0: Analizes a media file and writes the
3- gst-validate-media-check-1.0: Analyzes a media file and writes the
results to stdout or a file. It can also compare the results found with
another results file for identifying regressions. The monitoring lib
from gst-validate will be enabled during the tests to identify issues
with the GStreamer elements involved with the media file's container and
codec types. It will actually do a serie of checks over the media file.
codec types. It will actually do a series of checks over the media file.
Example:
@ -85,6 +85,6 @@ gst-validate will try to replace GstPipeline creating functions and configure
monitors automatically for you, reports will be printed to stderr when
they are found. You can also use GST_DEBUG to view the issues that were found
NOTS: The exit code will be "18" in case a critical issue has
NOTES: The exit code will be "18" in case a critical issue has
been seen while running any of those tools.

View file

@ -12,7 +12,7 @@
</refmeta>
<refnamediv>
<refname>GstValidate command line tools</refname>
<refpurpose>Documenation of the various command line tools provided by GstValidate</refpurpose>
<refpurpose>Documentation of the various command line tools provided by GstValidate</refpurpose>
</refnamediv>
<refsect1>
@ -38,7 +38,7 @@
It is the simplest tool and is used to run a gst
launch style pipeline. Monitors are added to it to identify issues in the
used elements. At the end a report will be printed, this report will
contain informations about all issues that were encontered while running
contain information about all issues that were encountered while running
gst-validate. To view issues as they are created, set the environment
variable GST_DEBUG=validate:2 and it will be printed as gstreamer
debugging. You can basically run any GstPipeline pipeline using it.
@ -123,7 +123,7 @@
<para>
<informalexample>
Moreover, you can set the <link linkend="gst-encoding-profile-set-presence">presence</link> property of an
encoding profile using the '|presence' synthax such as in:
encoding profile using the '|presence' syntax such as in:
<programlisting>video/webm:video/x-vp8|1:audio/x-vorbis</programlisting>
</informalexample>
@ -167,7 +167,7 @@
<informalexample>
A command line tool checking that media files discovering works properly with gst-discoverer. Basically it
needs a reference text file containing valid information about a media file (which can be generated with the same tool)
and then it will be able to check that those informations correspond to what is reported by gst-discoverer over new runs.
and then it will be able to check that those information correspond to what is reported by gst-discoverer over new runs.
For example, given that we have a valid reference.media_info file, we can run:
<programlisting>gst-validate-media-check-&GST_API_VERSION; file:///./file.ogv --expected-results reference.media_info</programlisting>
</informalexample>
@ -190,7 +190,7 @@
</para>
<para>
<informalexample>
You can find detailed informations about the launcher reading its help manual:
You can find detailed information about the launcher reading its help manual:
<programlisting>gst-validate-launcher --help</programlisting>
</informalexample>
</para>
@ -201,7 +201,7 @@
the test to be launched by the gst-validate-launcher.
</para>
<para>
In that example, we will concider that you want to write a whole new testsuite based on
In that example, we will consider that you want to write a whole new testsuite based on
your own media samples and <link linkend="ScenarioFileFormat">scenarios</link>.
That set of file and the testsuite implementation file will be structured as follow:
<synopsis>
@ -225,7 +225,7 @@ testsuite_folder/
<programlisting>gst-validate-media-check-&GST_API_VERSION; http://someonlinestream.com/thestream --output-file /path/to/testsuite_folder/sample_files/thestream.stream_info</programlisting>
</informalexample>
</para>
The gst-validate-launcher will use those .media_info and .stream_info files to generate the tests as those contain the necessary informations.
The gst-validate-launcher will use those .media_info and .stream_info files to generate the tests as those contain the necessary information.
<para>
</para>
<para>
@ -250,7 +250,7 @@ os.environ["GST_VALIDATE_SCENARIOS_PATH"] = \
validate.add_scenarios(["scenario", "scenario1"])
# Now add the thearo and vorbis in OGG as a wanted transcoding format. That means
# Now add the theora and vorbis in OGG as a wanted transcoding format. That means
# that tests with all the media files/streams will be converted to that format.
validate.add_encoding_formats([MediaFormatCombination("ogg", "vorbis", "theora")])
@ -279,7 +279,7 @@ validate.set_default_blacklist([
Run playbin pipelines on file.mp4, file1.mkv and file2.ogv executing "scenario" and "scenario1" scenarios
</listitem>
<listitem>
Transcode file.mp4, file1.mkv and file2.ogv to thearo and vorbis in OGG
Transcode file.mp4, file1.mkv and file2.ogv to theora and vorbis in OGG
</listitem>
</itemizedlist>
<informalexample>

View file

@ -25,22 +25,22 @@
<para>
This environment variable can be set to a list of debug options,
which cause GstValidate to print out different types of test result informations
and concider differently the level of the reported issues.
which cause GstValidate to print out different types of test result information
and consider differently the level of the reported issues.
<variablelist>
<varlistentry>
<term>fatal-criticals</term>
<listitem><para>Causes GstValidate to concider only critical issues as import enough to concider the test failed (default behaviour)</para>
<listitem><para>Causes GstValidate to consider only critical issues as import enough to consider the test failed (default behaviour)</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fatal-warnings</term>
<listitem><para>Causes GstValidate to concider warning, and critical issues as import enough to concider the test failed</para>
<listitem><para>Causes GstValidate to consider warning, and critical issues as import enough to consider the test failed</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fatal-issues</term>
<listitem><para>Causes GstValidate to concider issue, warning, and critical issues as import enough to concider the test failed</para>
<listitem><para>Causes GstValidate to consider issue, warning, and critical issues as import enough to consider the test failed</para>
</listitem>
</varlistentry>
<varlistentry>
@ -55,7 +55,7 @@
</varlistentry>
<varlistentry>
<term>print-criticals</term>
<listitem><para>Causes GstValidate to only print criticals issues in the final reports</para>
<listitem><para>Causes GstValidate to only print critical issues in the final reports</para>
</listitem>
</varlistentry>
</variablelist>

View file

@ -25,12 +25,12 @@
The name of the scenario is the name of the file without its '.scenario' extension.
The scenario file file format is based on the <link linkend="GstStructure"><type>GstStructure</type></link> serialized format which is a basic, type aware,
key value format.
It takes the type of the action as first coma separeted field, and then
It takes the type of the action as first coma separated field, and then
the key values pair of the form 'parameter=value' separated by comas. The values
type will be guessed if not casted as in 'parameter=(string)value'. You can force the type
guessing system to actually know what type you want by giving it the right hints. For example
to make sure the value is a double, you should add a decimal (ie '1' will be concidered as a
int, but '1.0' will be concidered as a double and '"1.0"' will be concidered as a string)
to make sure the value is a double, you should add a decimal (ie '1' will be considered as a
int, but '1.0' will be considered as a double and '"1.0"' will be considered as a string)
</para>
<para>
For example to represent a seek action, you should add the following line in the '.scenario'
@ -53,7 +53,7 @@
Each line in the '.scenario' file represent an action (you can also use \ at the end of a line
write a single action on multiple lines). Usually you should start you scenario with a 'description'
"config" action in order for the user to have more information about the scenario. It can contain
a 'summary' field which is a string explaning what the scenario does and then several info fields
a 'summary' field which is a string explaining what the scenario does and then several info fields
about the scenario. You can find more info about it running:
</para>
<para>