mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-01-23 23:58:17 +00:00
validate:docs: fix spelling mistakes
https://bugzilla.gnome.org/show_bug.cgi?id=736160
This commit is contained in:
parent
3755581fd3
commit
1a8b460d23
5 changed files with 26 additions and 26 deletions
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
Loading…
Reference in a new issue