This test will find the first input selector with more than one
sink pad, and cycle through them till it gets back to the original
one. Five seconds between switches. The test checks that some data
was sent from the input selector when each of the sink pads was
selected.
We know are sequential so whenever the wanted position is passed we
should execute the action.
This avoid issue with the tolerance when we have high rate playback
Testing on source pads can lead to false positives when pads are
unlinked. The caps event is sticky and will be pushed again later
when another buffer/event is pushed, leading to an acceptable
situation to push the caps twice.
When seeking we might want to execute seeks at a playback time inferior than previous
seek, so we need to be able to define the order in which actions have to be
executed, the simplest way is to just concider that actions are always
order in the XML files.
+ Add some more debugs
Conflicts:
gst/validate/gst-validate-scenario.c
Update to have the same features as gst-validate.
1) Handle interrupts properly, with the additional of having the
'eos-on-shutdown' argument that sends EOS to the pipeline. This is
very useful for transcoding processes to finish correctly.
2) Print issues on the end of application
Adds a new expected-results argument to receive a file that is used
as a base for comparison with the new results. In case differences are
found, the application will print those issues.
They weren't waiting for the pipeline to properly change state
before sending seek events, that would cause some events to
return TRUE even if they were not handled
The tests are very simple as they only write the first error they
found during playback. If no error is set, an empty string is
printed.
The playback pipeline isn't monitored with validate monitors for now
This struct stores information about a media and tests run on it. It
also has a few helper functions that allows storing the results to a
file and loading it back.
Instead of having the file-checker object that would compare the
extracted values from the file to expected results set to its properties,
the media-info will store the values and it will be possible to compare
old media-info with new media-info from the same file. This allows
tracking improvements and regressions on different gstreamer versions.
Right now, the media-info is very tiny and doesn't store much info, only
the uri and the file size in bytes, but it will receive more additions in
the upcoming commits for storing duration, media topology, seekability and
playback information.
