Even when pulling a new 64KB buffer from upstream, don't return
more data than was asked for in the pull_range() method and then
return less later, as that confused subclasses like h264parse.
Add a unit test that when a subclass asks for more data, it always
receives a larger buffer on the next iteration, never less.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/-/issues/530
When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
What may happen is that during the course of processing a buffer,
all of the pads in a flow combiner may disappear. In this case, we
would return NOT_LINKED. Instead return whatever the input flow return
was.
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
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.
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.
Post instant-rate-request message when receiving an instant-rate-change
event, and handle the incoming instant-rate-sync-time events from the
pipeline.
If the expected size is bigger than the actual buffer size, it would
memcmp random memory which could lead to crashes instead of proper error
reporting.
The virtual method named `get_caps` in both `GstBaseSrc` and
`GstBaseSink` has a `filter` parameter which can be `NULL` (the
default implementation in GstBaseSrc already considers the case).
Before this commit, there was no gtk-doc annotation representing this
fact, which caused the corresponding entry in the GIR file to also
miss this fact.
This caused bugs in other places, such inducing the Vala compiler to
introduce a wrongly assert on `(filter != NULL)` in every
implementation of the `get_caps` method implemented in Vala.
By passing NULL to `g_signal_new` instead of a marshaller, GLib will
actually internally optimize the signal (if the marshaller is available
in GLib itself) by also setting the valist marshaller. This makes the
signal emission a bit more performant than the regular marshalling,
which still needs to box into `GValue` and call libffi in case of a
generic marshaller.
Note that for custom marshallers, one would use
`g_signal_set_va_marshaller()` with the valist marshaller instead.
../libs/gst/check/libcheck/check.c:617:15: error: result of comparison of constant 4294967295 with expression of type 'clockid_t' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (clockid == -1) {
~~~~~~~ ^ ~~
Silence -Wformat-nonliteral warnings from the internal copy of libcheck
../subprojects/gstreamer/libs/gst/check/libcheck/check.c:379:29: warning: format string is not a string literal [-Wformat-nonliteral]
vsnprintf (buf, BUFSIZ, msg, ap);
^~~
../subprojects/gstreamer/libs/gst/check/libcheck/check_error.c:48:21: warning: format string is not a string literal [-Wformat-nonliteral]
vfprintf (stderr, fmt, args);
^~~
../subprojects/gstreamer/libs/gst/check/libcheck/check_str.c:92:29: warning: format string is not a string literal [-Wformat-nonliteral]
n = vsnprintf (p, size, fmt, ap);
^~~
Otherwise it can happen that we start waiting for another pad, while one
pad already has events that can be handled and potentially also a buffer
that can be handled. That buffer would then however not be accessible by
the subclass from GstAggregator::get_next_time() as there would be the
events in front of it, which doesn't allow the subclass then to
calculate the next time based on already available buffers.
As a side-effect this also allows removing the duplicated event handling
code in the aggregate function as we'll always report pads as not ready
when there is a serialized event or query at the top of at least one
pad's queue.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/428
The install kwarg on configure_file() was only added in
Meson 0.50 but we're targetting older versions as well,
which caused a warning. The install kwarg is not needed
here as we specify install_dir, so we can just drop it.
Fixes#379
The documentation says that this allows the subclass to signal that it
needs more data before it can decide on caps, so let's actually
implement it that way.
This is similar to what demuxers do, and necessary when multiple
sinks get seeked downstream of the aggregator: if we forward
duplicated seeks upstream, elements such as demuxers may drop
the flushing seeks, but return TRUE, aggregator then waits forever
for the flushing events.
Fixes#276
When passing "sink_%d" twice to aggregator before it would create two
pads called "sink_0", because it failed to parse "%d" as integer and
used 0 instead then.
Instead validate that parsing was actually successful and also don't
even try to parse if the requested pad name contains a '%'.
strcmp() does not allow the arguments to be NULL, but g_strcmp0()
does, so document that we use g_strcmp0() so that people don't need to
worry about that.
At the moment, we can only use crank if the pending entry is in the
future. This patch leaves the clock time to the same point if the
pending entry was in the past. This still execute a single entry. This
will be needed for the jitterbuffer, since as soon as we stop waking up
the jitterbuffer when the timer is reschedule later, we may endup with
such case in the unit tests.
Related to #608
By only having it on sinkpad-creation, it is racy to write a test
with a sometimes-pad (like a demuxer) that you want to pull from, having
the pull wait until the pad arrives and the buffer can be produced.
For the query function there's a risk that the function may be called
after the harness has been teared down. Since the function accesses a
pointer to the harness via the pad's data, the harness must protect
itself against this.
Event and chain function is also handled for constistency, although
they don't have the same problem since the gstpad.c checks whether the
pad is flushing before calling these.
