This has the same function as the negotiate() functions in various other
base classes and is required to be able to completely re-implement
submit_input_buffer() in subclasses.
When we do not have any information about DTSs we shouldn't try to make
them up, moreover after seeking `segment->start` has nothing to do with
the next buffer timing (and is probably after the actual buffer timestamp)
and since, since fa8312472f
we do:
```
if (buffer->dts > buffer->dts)
buffer->pts = buffer->dts
```
we end up setting `buffer->pts = segment->start` which is plain
broken and leads to downstream decoder accept the first buffer
as it will be inside the segment (its pts==segment->start) which
basically means accurate seeking behaves mostly the same way as
keyframe seeks.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/492
GST_CLOCK_TYPE_TAI is GStreamer abstraction for CLOCK_TAI. Main
motivation for this patch is support for transmission offloading features
- when network packets are timestamped with the time they are deemed to
be actually transmitted. Linux API for that requires that time to be
in CLOCK_TAI coordinate.
With GST_CLOCK_TYPE_TAI, applications can use CLOCK_TAI directly on
their pipelines, avoiding the need to cross timestamp packet times. By
leveraging system's CLOCK_TAI, applications also don't need to keep track
of leap seconds - less burden for them. Just keep system's CLOCK_TAI
accurate and use it.
This would cause us to set GST_GROUP_ID_INVALID as group-id in the
aggregated STREAM_START message if there are no sinks at all or none of
them have a STREAM_START message, which is simply wrong.
If we have not a single STREAM_START message then the bin should not be
considered STREAM_START.
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
