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
* Some SEGMENT might be updates caused by calling gst_pad_set_offset(),
which will send the same segment but with an updated offset and/or
based field. For those segments, we don't require a DISCONT on the
following buffer.
* Ignore differences in flags, they aren't relevant for now to figure
out whether the segment is an update or not
* Ignore difference in 'position', it's only meant for internal usage
by elements.
* Changes in the end position (stop in forward playback and start in
reverse playback) are considering updates
Furthermore, also expect a DISCONT flag on the first buffer following
a STREAM_START.
When a first testsuite will set paths, it does not mean that we should
just register following testsuite test manager default tests.
So we need to make a difference between the media paths the user passed
with --media-path and the ones defined by the testsuite.
After a seek we need to wait for the right segment (meaning the segment
with seqnum == last seek/flush stop seqnum) to check whether the segment.time
has been properly set.
In the case and element is in READY or is going to READY state, it can
always return GST_FLOW_FLUSHING.
Avoid a race where a demuxer sinkpad has not been set to FLUSHING when we are
still processing a buffer but downstream is already FLUSHING and thus
the demuxer is already returning FLUSHING.
