While we can fixe the upstream latency using the min-upstream-latency, we
are now forced to use queues (hence more thread) in order to store the pending
data whenever we have an upstream source that has lower latency.
This fixes the issue by allowing to buffer the fixed upstream latency. This is
particularly handy on single core systems were having too many threads can
cause serious performance issues.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/684>
When going to PLAYING we will now have a clock and can stop waiting on
the condition variable and instead start waiting on the clock if
necessary for the current configuration.
In the other direction when going to PAUSED the clock might have
disappeared and we might need to wait on the condition variable again
instead.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/653>
On the first buffer the base class would update the segment position
based on the start-time-selection. If the subclass provides its own
segment this will caused unexpected behaviour and override segment
information that was explicitly set by the subclass.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/600>
See https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/issues/771
for context.
This exposes new API that subclasses must call from their
aggregate() implementation to signal that they have selected
the next samples they will aggregate: gst_aggregator_selected_samples()
GstAggregator will emit a new signal there, `samples-selected`,
handlers can then look up samples per pad with the newly-added
gst_aggregator_peek_next_sample.
In addition, a new FIXME is logged when subclasses haven't actually
called `selected_samples` from their aggregate() implementation.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/549>
Make g-ir-scanner skip all those check macros that are
not useful for or usable from bindings.
gstcheck.h:209: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_message_error'
gstcheck.h:212: Warning: GstCheck: Unknown namespace for symbol 'assert_message_error'
gstcheck.h:251: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int'
gstcheck.h:267: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int'
gstcheck.h:280: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int_hex'
gstcheck.h:299: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int_hex'
gstcheck.h:310: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int64'
gstcheck.h:327: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int64'
gstcheck.h:340: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_int64_hex'
gstcheck.h:358: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_int64_hex'
gstcheck.h:369: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_uint64'
gstcheck.h:386: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_uint64'
gstcheck.h:399: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_uint64_hex'
gstcheck.h:417: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_uint64_hex'
gstcheck.h:428: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_string'
gstcheck.h:444: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_string'
gstcheck.h:455: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_float'
gstcheck.h:474: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_float'
gstcheck.h:487: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_pointer'
gstcheck.h:506: Warning: GstCheck: Unknown namespace for symbol 'assert_equals_pointer'
gstcheck.h:517: Warning: GstCheck: Unknown namespace for symbol 'fail_unless_equals_clocktime'
gstcheck.h:534: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREADS'
gstcheck.h:547: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREAD_FUNCTIONS'
gstcheck.h:555: Warning: GstCheck: Unknown namespace for symbol 'MAIN_START_THREAD_FUNCTION'
gstcheck.h:626: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CRITICAL'
gstcheck.h:628: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CRITICAL'
gstcheck.h:640: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_WARNING'
gstcheck.h:652: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_OBJECT_REFCOUNT'
gstcheck.h:661: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_OBJECT_REFCOUNT_BETWEEN'
gstcheck.h:676: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_CAPS_REFCOUNT'
gstcheck.h:679: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_BUFFER_REFCOUNT'
gstcheck.h:682: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_MINI_OBJECT_REFCOUNT'
gstcheck.h:690: Warning: GstCheck: Unknown namespace for symbol 'ASSERT_SET_STATE'
gstcheck.h:729: Warning: GstCheck: Unknown namespace for symbol 'tcase_skip_broken_test'
gstcheck.h:740: Warning: GstCheck: Unknown namespace for symbol 'tcase_skip_broken_loop_test'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
It was zero and in some condition it means that the control binding
values where ignored (as shown in the test). Setting it to MAXDOUBLE
so that the first time we sync the values from a a timestamp in the
right range the proper value is computed.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/564>
In reverse playback, buffers have to be displayed at buffer.stop running
time, otherwise a same set of buffer can't be displayed in the exact opposite
order to forward playback.
For example, seeking a video stream at 1fps with start=0, stop=5s, rate=1.0
will display the following buffers:
b0.pts = 0s, b0.duration = 1s - at running time = 0s
b1.pts = 1s, b1.duration = 1s - at running time = 1s
b2.pts = 2s, b2.duration = 1s - at running time = 2s
b3.pts = 3s, b3.duration = 1s - at running time = 3s
b4.pts = 4s, b4.duration = 1s - at running time = 4s
<wait at EOS for 1second>
Now, playing that reverse with start=0, stop=5s, rate=1.0 has to display
the following buffers:
b0.pts = 4s, b0.duration = 1s - at running time = 0s
b1.pts = 3s, b1.duration = 1s - at running time = 1s
b2.pts = 2s, b2.duration = 1s - at running time = 2s
b3.pts = 1s, b3.duration = 1s - at running time = 3s
b4.pts = 0s, b4.duration = 1s - at running time = 4s
<wait at EOS for 1second>
With the previous code, it reproduced the following:
b0.pts = 4s, b0.duration = 1s - at running time = 1s
b1.pts = 3s, b1.duration = 1s - at running time = 2s
b2.pts = 2s, b2.duration = 1s - at running time = 3s
b3.pts = 1s, b3.duration = 1s - at running time = 4s
b4.pts = 0s, b4.duration = 1s - at running time = 5s
<NO WAIT AT EOS AND POST EOS RIGHT AWAY>
This is being tested with the `validate.launch_pipeline.sink.reverse_playback_clock_waits.*`
set of tests
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
In reverse playback, buffers are played back from buffer.stop
(buffer.pts + buffer.duration) to buffer.pts, which means that the
position after the buffer is consumed is buffer.pts, not buffer.pts -
buffer.duration.
Without that change, and when `automatic_eos` feature is on,
we were dropping the last buffers as marking the stream EOS one buffer
too soon.
This is now being tested extensively by GstValidate in the
`validate.test.clock_sync.*` set of tests.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/450>
To allow the refcounting tracer to work better. In childproxy/iterator
these might be plain GObjects but gst_object_unref() also works on them.
In other places where it is never GstObject, g_object_unref() is kept.
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.
