This is useful when you want to check only the demuxer output.
- Keep the information in the media file so that we can launch media-check
with the proper arguments in the launcher. Update it accordingly.
- Refactor compare_streams to simplify it, which in the end leads to
reporting all the issues instead of exiting on the first one.
In file included from ../subprojects/gst-devtools/validate/tools/gst-validate-rtsp-server.c:21:0:
.../gst/gst.h:31:10: fatal error: gst/gstenumtypes.h: No such file or directory
The fact that Scenario.pipeline was not accessible in a thread way lead
to the fact that all users had to take the unref the last pipeline ref
in the main thread, otherwise we were crying. This was an ugly
restriction which lead to issue when using scenario on gst-rtsp-server.
This break the API as this commit remove the GstValidateScenario.pipeline
field but it is worth it.
GOptionEntry's arg_data is of type gpointer which differs in
constness from const gchar*, so remove constness from outfolder.
This fixes a build issue with msvc.
https://bugzilla.gnome.org/show_bug.cgi?id=782031
It makes no sense to pause the pipeline and wait for buffering to be
done when the pipeline is just processing the data as it comes
in without synchronizing on the clock.
This allows validate to clean up before the 'leak' tracer list leaked
objects.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1231
Pads returned using the playbin get-{audio,video}-pad are reffed.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1027
My patch fixing monitor leak (15e7f1bbfd)
introduced a ref cycle between GstValidateReporter and
GstValidateReport.
The reports uses its reporter so it needs a ref on it
to ensure it's stay alive. But reports are owned by GstValidateReporter and/or
GstValidateRunner.
The best way I found to break this cycle is to introduce this purge
method. It's not great but the design is a bit tricky.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1029
When doing a track switch, the only reliable way to detect that it
happened is whether a new STREAM_START arrives.
Relying on a DISCONT buffer is not satisfactory, since there might
not have been an element setting that flag upstream.
Checking whether the first buffer after a STREAM_START has the
DISCONT flag properly set should be done in parallel
