We now have GstTestClock-based tests that validate the same logic,
without inducing spurious timing failures / overly relying on sleeps.
Fixes: #346Fixes: #347Fixes: #348
Co-authored by: Thibault Saunier <tsaunier@igalia.com>
There was a case where we started waiting on the clock before setting
the clock time, leading to the wait succeeding instead of being late:
gsttestclock.c:1073:F:testclock:test_late_crank:0: '1 * GST_SECOND' (1000000000) is not equal to 'context.jitter' (-4000000000)
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/426
Co-authored by: Mathieu Duponchelle <mathieu@centricular.com>
A common use case of a dynamically built pipeline is that you want to
(conditionally) find a certain element, e.g. the `rtpbin`s in a
`uridecodebin`. If that element has a fixed name inside its parent bin
(and only has a single instance) this can be easily done by
`gst_bin_get_by_name()`.
If there are multiple instances of the element however, you can only use
`gst_bin_iterate_all_by_interface()`, but this doesn't work if you don't
have the specific `GType` (which is often the case, due to plugins being
dynamically loaded). As such, another fallback could be to use the
well-known name of the element's factory (in case of our example, this
is of course `"rtpbin"`).
Fixes#345
There were two causes for the flakiness, one much rarer than
the other.
The test sets up a source with a sometimes pad added during
the transition of a wrapper bin from READY to PAUSED.
It runs 4 iterations, the last of which makes it so the
negotiation fails.
In that case, the intention as correctly presented by the following
comment:
/* [..] ie, the pipeline should create ok but fail to change state */
However the implementation of run_delayed_test was neither calling
get_state on the pipeline (it called it on the wrapper bin), nor
checking that the return of get_state was FAILURE (it actually
checked that it was not).
This led to an obvious race condition, and was fixed by calling
get_state on the pipeline, then checking that in this specific
case (expect_link == FALSE), the state change has actually failed.
The second, rarer race condition is at set_state time. When we
don't expect the link to succeed, the return of set_state may
either be FAILURE or ASYNC, depending on timing. This was fixed
by taking expect_link into account when checking the return value
of set_state.
Co-authored by: Thibault Saunier <tsaunier@igalia.com>
According to [1] EINTR is a possible errno for fsync(),
so handle it as all other EINTR (do/while(errno == EINTR)).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
According to [1] EINTR is a possible errno for fsync(),
so handle it as all other EINTR (do/while(errno == EINTR)).
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
According to [1] EINTR is a possible errno for fsync() and it happens in
reality on linux (video writing via splitmuxsink with robust muxing enabled
on a cifs mounted network share), so handle it as all other EINTR
(do/while(errno == EINTR)).
Fixes:
GError.message: Error while writing to file "vidoe_001.mp4". GError.domain: 2372 GError.code: 10 from: FileSink debug: gstfilesink.c(849): gst_file_sink_render (): /GstPipeline:Pipeline/GstSplitMuxSink:SplitMuxSink/GstBin:QueueBin/GstFileSink:FileSink: Interrupted system call
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
As soon as gstcheck potentially calls out to code it does not
control, such as gst_element_request_pad, all assertions about
pad refcounts go out the window.
Without this it is possible that we have a GSource with reference count
0 stored in the GstBus that is currently in the process of being
destroyed. gst_bus_remove_watch() might then access it, increase its
reference count to 1 again, call GSource API on it and then unref it,
which will then finalize it a second time.
The dispose function allows the GSource to be resurrected until it
returned so the above would be safe now.
This caused some spurious crashes during shutdown in various
applications.
We were checking to make sure the buffer's DTS wouldn't be after its
PTS. However, the check would also trigger when DTS is NONE, which is
e.g. in the case of some broken cameras.
Fixes#470
If, for example, we are accumulating rounding errors from the buffer
duration when calculating the PTS/DTS, it can happen that the buffer
thinks it should be presented before it's decoded. In that case we just
clamp the DTS.
It fixes below gir warnings.
../subprojects/gstreamer/gst/gstevent.c:2246: Warning: Gst:
gst_event_new_instant_rate_sync_time: unknown parameter
'rate_multiplier' in documentation comment, should be 'rate'
../subprojects/gstreamer/gst/gstevent.c:2296: Warning: Gst:
gst_event_parse_instant_rate_sync_time: unknown parameter
'rate_multiplier' in documentation comment, should be 'rate'
After release bison 2.5 the declaration %pure-parser was deprecated
in favor of %define api.pure
Nonetheless, until bison 3.4, the declaration was treated as backward
compatibility, but now bison shows a warning:
warning: deprecated directive, use ‘%define api.pure’
The patch's approach is to handle both directives according with the
used bison's version, by string replacement at source configuration
stage.
When playing gapless there were situations when some sticky events
like tags were stuck at some pad and then revived much later.
Therefore it is better to clear them upon stream-start.
Fixes#360
Post instant-rate-request message when receiving an instant-rate-change
event, and handle the incoming instant-rate-sync-time events from the
pipeline.
A seek with that flag set must be non-flushing, not change the playback
direction and start/stop position. A seek handler will then send the new
GST_EVENT_INSTANT_RATE_CHANGE event downstream for downstream elements
to immediately apply the new playback rate before the new in-band segment
event arrives.
`g_object_notify()` actually takes a global lock to look up the
`GParamSpec` that corresponds to the given property name. It's not a
huge performance hit, but it's easily avoidable by using the
`_by_pspec()` variant.
This reverts a96002bb28, which is not
necessary anymore. If we release the pad after removing it then none of
the deactivation code will actually be called because the pad has no
parent anymore, and we require a parent on the pad for deactivation to
happen.
This can then, among other things, cause a streaming thread to be still
stuck in a pad probe because the pad was never flushed, and waiting
there forever because now the pad will actually never be flushed anymore.
If a pad is currently being released we don't want to forward the
FLUSHING flow return but instead consider it as NOT_LINKED. FLUSHING
would also cause upstream to be FLUSHING.
This part was missed in a3c4a3201a and
resulted in a different (and wrong) workaround in
a96002bb28.
Otherwise we're not guaranteed to read the very latest value that
another thread might've written in there when the pad was released, and
could instead work with an old value.
This can be made to work in certain circumstances when
cross-compiling, so default to not building g-i stuff
when cross-compiling, but allow it if introspection was
enabled explicitly via -Dintrospection=enabled.
Fixes#454 and #381.
