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.
Fix this by not taking a reference on the reporter but instead caching
its name.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1029
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
A GHashTableIter is invalided if the hash table is modified while we are
iterating. Prevent this by taking the runner lock.
Fix assertion warnings with
validate.file.transcode.to_vorbis_and_vp8_in_webm.Sintel_2010_720p_mkv_srt
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1026
Add to deploy setup_sink_props_max_lateness scenario.
When running gst-validate with valgrind option on the installed package, it fails to find that scenario.
Reviewed-by: Guillaume Desmottes <guillaume.desmottes@collabora.co.uk>
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D379
Only expect fully identical stream-id from URI which are not local files
nor from our local http server.
Fixes issues with non-default http server port
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
gst-validate-scenario.c:183:7: error: '_gst_validate_action_type' redeclared without dllimport attribute: previous dllimport ignore
This is also declared in gst-validate-internal.h
As this is what user will expect in this case.
For example with this scenario:
set-state, state=null; playback-time=5
set-property, target-element-name=dvbsrc0, property-name=delsys, property-value=11
play;
Instead of providing full absolute path while validating the file, should be
able to provide the relative path with respect to the present directory.
https://bugzilla.gnome.org/show_bug.cgi?id=753494
The monitor returned by gst_validate_monitor_factory_create() was never
unreffed.
Report instances now have to keep a ref, as suggested by the TODO, as
the reporter is no longer leaked.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1012
The gstvalidate_debug may not be initialized like with the
validate/reporting which was crashing when run with GST_DEBUG=5.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D1004
The 'all_raw_caps' list is never used and was just leaking caps.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D979
- the pad returned by gst_element_get_static_pad() was leaked.
- unref the pad from snode when updating it, not the pad passed as
callback to pad_added_cb()
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D958
_add_override_from_struct() could, in theory, register more than once
the same override so we should not transfer the ref.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D956
Makes fixing easier as then we can just re-use the generated trace.
Reviewed-by: Thibault Saunier <tsaunier@gnome.org>
Differential Revision: https://phabricator.freedesktop.org/D953
