They are optional on STREAM_START messages/events but if available
should have at least a valid value.
For STREAM_GROUP_DONE events don't allow creating it with an invalid
group id as this does not make any sense.
Errors causing the pipeline to fail going from NULL to PAUSED
were not displayed, and the pipeline was not dumped either in
those cases.
In addition, dumping the pipeline from the sync handler means
the dump matches exactly the state of the pipeline at the
moment the error was posted.
Introducing "GST_PLUGIN_FEATURE_RANK" environment variable in order for users
to adjust rank of plugin(s) via environment.
A "feature" and "rank" key-value pair should be separable by ":",
and each key-value pair is recognized per "," delimiters. The rank
can be a numerical value or one of pre-defined rank values
such as "NONE", "MARGINAL", "SECONDARY", and "PRIMARY" in case-insensitive manner.
In addition to pre-defined { NONE, MARGINAL, SECONDARY, PRIMARY },
"MAX" can be passed to key value used to ensure having a higher rank
than other plugin features.
Example)
- GST_PLUGIN_FEATURE_RANK=qtdemux:256,h264parse:NONE
Set rank of qtdemux plugin to 256 (primary) and 0 (none) for h264parse.
If you're using a custom log handler, you had to reverse-engineer the
debug log format and create your own format function. Now, you can
call `gst_debug_log_get_line()` and it will return a string (without
ANSI escape color codes) representation instead.
This is useful in situations when you need to log the ordinary
gst_debug log to a resource that can't be opened as a `FILE` handle.
Also includes a test.
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.
