diff --git a/validate/docs/validate-design.txt b/validate/docs/validate-design.txt index 623c8910df..04cb31c43a 100644 --- a/validate/docs/validate-design.txt +++ b/validate/docs/validate-design.txt @@ -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 diff --git a/validate/docs/validate-usage.txt b/validate/docs/validate-usage.txt index 2d64288be0..44df3d7a1a 100644 --- a/validate/docs/validate-usage.txt +++ b/validate/docs/validate-usage.txt @@ -7,7 +7,7 @@ directly with the path tools/ 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 @@ -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. diff --git a/validate/docs/validate/command-line-tools.xml b/validate/docs/validate/command-line-tools.xml index 1b7812564d..32df7ddf04 100644 --- a/validate/docs/validate/command-line-tools.xml +++ b/validate/docs/validate/command-line-tools.xml @@ -12,7 +12,7 @@ GstValidate command line tools - Documenation of the various command line tools provided by GstValidate + Documentation of the various command line tools provided by GstValidate @@ -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 @@ Moreover, you can set the presence property of an - encoding profile using the '|presence' synthax such as in: + encoding profile using the '|presence' syntax such as in: video/webm:video/x-vp8|1:audio/x-vorbis @@ -167,7 +167,7 @@ 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: gst-validate-media-check-&GST_API_VERSION; file:///./file.ogv --expected-results reference.media_info @@ -190,7 +190,7 @@ - You can find detailed informations about the launcher reading its help manual: + You can find detailed information about the launcher reading its help manual: gst-validate-launcher --help @@ -201,7 +201,7 @@ the test to be launched by the gst-validate-launcher. - 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 scenarios. That set of file and the testsuite implementation file will be structured as follow: @@ -225,7 +225,7 @@ testsuite_folder/ gst-validate-media-check-&GST_API_VERSION; http://someonlinestream.com/thestream --output-file /path/to/testsuite_folder/sample_files/thestream.stream_info - 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. @@ -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 - 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 diff --git a/validate/docs/validate/envvariables.xml b/validate/docs/validate/envvariables.xml index dd9c76b6db..1a64edc185 100644 --- a/validate/docs/validate/envvariables.xml +++ b/validate/docs/validate/envvariables.xml @@ -25,22 +25,22 @@ 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. fatal-criticals - Causes GstValidate to concider only critical issues as import enough to concider the test failed (default behaviour) + Causes GstValidate to consider only critical issues as import enough to consider the test failed (default behaviour) fatal-warnings - Causes GstValidate to concider warning, and critical issues as import enough to concider the test failed + Causes GstValidate to consider warning, and critical issues as import enough to consider the test failed fatal-issues - Causes GstValidate to concider issue, warning, and critical issues as import enough to concider the test failed + Causes GstValidate to consider issue, warning, and critical issues as import enough to consider the test failed @@ -55,7 +55,7 @@ print-criticals - Causes GstValidate to only print criticals issues in the final reports + Causes GstValidate to only print critical issues in the final reports diff --git a/validate/docs/validate/scenarios.xml b/validate/docs/validate/scenarios.xml index b363534feb..1ad305b8e4 100644 --- a/validate/docs/validate/scenarios.xml +++ b/validate/docs/validate/scenarios.xml @@ -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 GstStructure 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) 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: