![]() |
![]() |
![]() |
![]() |
GstValidate Command line toolsGstValidate command line tools — Documentation of the various command line tools provided by GstValidate |
In order to make gst-validate usage simple, dedicated tools that allow plugin developers test there elements in many use cases from a high level perspective are provided with GstValidate.
gst-validate: The simplest gst-launch like pipeline launcher running inside GstValidate monitoring infrastructure gst-validate-transcoding: A tool to easily create media files transcoding pipeline running inside GstValidate monitoring infrastructure * Encoding Profile: The serialization format of a GstEncodingProfile gst-validate-media-check: A tool to easily check that the discovering of a media file works properly over runs gst-validate-launcher: An application permitting to create testsuites on top of GstValidate tools * The default testsuite The default GstValidate testsuite * Implementing a testsuite How to implement a testsuite
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 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. If you are not familiar with gst-launch syntax, please refer to gst-launch's documentation.
gst-validate-1.0 playbin uri=file:///path/to/some/media/fileTranscoding pipeline:
gst-validate-1.0 filesrc location=/media/file/location ! qtdemux name=d ! queue ! x264enc ! h264parse ! mpegtsmux name=m ! progressreport ! filesink location=/root/test.ts d. ! queue ! faac ! m.
issue : buffer is out of the segment range Detected on theoradec0.srcpad at 0:00:00.096556426 Details : buffer is out of segment and shouldn't be pushed. Timestamp: 0:00:25.000 - duration: 0:00:00.040 Range: 0:00:00.000 - 0:00:04.520 Description : buffer being pushed is out of the current segment's start-stop range. Meaning it is going to be discarded downstream without any use
The return code of the process will be 18 in case a CRITICAL issue has been found
gst-validate-transcoding-1.0 file:///./file.ogg file:///.../transcoded.webm -o 'video/webm:video/x-vp8:audio/x-vorbis'
issue : buffer is out of the segment range Detected on theoradec0.srcpad at 0:00:00.096556426 Details : buffer is out of segment and shouldn't be pushed. Timestamp: 0:00:25.000 - duration: 0:00:00.040 Range: 0:00:00.000 - 0:00:04.520 Description : buffer being pushed is out of the current segment's start-stop range. Meaning it is going to be discarded downstream without any use
The return code of the process will be 18 in case a CRITICAL issue has been found
Internally the transcoding application uses GstEncodeBin. gst-validate-transcoding-1.0 uses its own serialization format to describe the GstEncodeBin.profile property of the encodebin.
muxer_source_caps:videoencoder_source_caps:audioencoder_source_caps
video/webm:video/x-vp8:audio/x-vorbis
video/webm:video/x-vp8+youtube-preset:audio/x-vorbis
video/webm:video/x-vp8|1:audio/x-vorbis
This field allows you to specify how many times maximum a GstEncodingProfile can be used inside a encodebin.
You can also use the 'restriction_caps->encoded_format_caps' to specify the restriction caps to be set on a GstEncodingProfile. It corresponds to the restriction GstCaps to apply before the encoder that will be used in the profile. The fields present in restriction caps are properties of the raw stream (that is before encoding), such as height and width for video and depth and sampling rate for audio. This property does not make sense for muxers.
video/webm:video/x-raw-yuv,width=1920,height=1080-->video/x-vp8:audio/x-vorbis
gst-validate-media-check-1.0 file:///./file.ogv --expected-results reference.media_info
That will then output found errors if any and return an exist code different from 0 if an error was found.
As you can notice, those tools let us test static pipelines execution and not that the pipeline reacts properly during execution of actions from the end user such as seeking, or changing the pipeline state, etc… In order to make that possible and easy to use we introduced the concept of scenarios
To be able to implement actual testsuite based on the previously described command line tools, a test launcher has been developed: gst-validate-launcher.
gst-validate-launcher --help
GstValidate comes with a default testsuite to be executed on a default set of media samples. Those media samples are stored with git-annex so you will need it to be able to launch that default testsuite.
gst-validate-launch validate --sync
This will only launch the GstValidate tests and not other application that might be supported (currently ges-launch is also supported and has its own default testsuite).
gst-validate-launch validate --sync --mute
To implement a testsuite, you will have to write some simple python code that will define the test to be launched by the gst-validate-launcher.
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:
testsuite_folder/ |-> testsuite.py |-> sample_files/ |-> file.mp4 |-> file1.mkv |-> file2.ogv |-> scenarios |-> scenario.scenario |-> scenario1.scenario
gst-validate-launch --medias-paths /path/to/sample_files/ --generate-media-infoFor remote streams, you should use gst-validate-media-check-1.0. For an http stream you can for example do:
gst-validate-media-check-1.0 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 information.
Then you will need to write the testsuite.py file. You can for example implement the following testsuite:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
import os # Make sure gst-validate-launcher uses our special media files options.paths = os.path.dirname(os.path.realpath(__file__)) # Make sure GstValidate will be able to use our special scenarios # from the testsuite_folder/scenarios folder os.environ["GST_VALIDATE_SCENARIOS_PATH"] = \ os.path.join(os.path.dirname(os.path.realpath(__file__)), "scenarios") # You can activate the following if you care only about the critical issues in # the report: # os.environ["GST_VALIDATE"] = "print_criticals" # Make gst-validate use our scenarios validate.add_scenarios(["scenario", "scenario1"]) # 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")]) # Use the GstValidatePlaybinTestsGenerator to generate tests that will use playbin # and GstValidateTranscodingTestsGenerator to create media transcoding tests that # will use all the media format added with validate.add_encoding_formats validate.add_generators([validate.GstValidatePlaybinTestsGenerator(validate), GstValidateTranscodingTestsGenerator(self)]) # Blacklist some test that are known to fail because a feature is not supported # or any reason. # The tuple defining those tests is of the form: # ("regex defining the test name", "Reason why the test should be disabled") validate.set_default_blacklist([ ("validate.*.scenario1.*ogv$" "oggdemux does not support some action executed in scenario1")] ) |
Once this is done, we got a testsuite that will:
gst-validate-launcher --config /path/to/testsuite_folder/testsuite.py