Usually the latency message is only posted whenever latency of an
element changes but that might be too early as the sinks might not be
able to query the latency at that point yet.
Similarly adding a new sink should cause latency reconfiguration once
that new sink is able to report its latency.
This fixes latency configuration in pipelines where webrtcbin is the
only "sink", i.e. it is used in a sendonly session. Before, the latency
would always be configured to 0.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/843>
Ensures that all unused threads are exited before the atexit()
handlers run.
This prevents a race with any thread that used the OpenSSL library
between it's thread cleanup routine and it's atexit() cleanup routine
which can cause a SIGSEGV.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/812>
The name `gst_element_get_request_pad()` is confusing to people
learning GStreamer. `gst_element_request_pad_simple()` aims at
providing the exact same functionality, while making it more
explicit it is a simplified `gst_element_request_pad()`.
`gst_element_request_pad_simple()` is consistent with other
functions such as `gst_element_seek_simple`.
This commit deprecates `gst_element_get_request_pad()` so that a
compilation warning is emitted when used and incite developers
to use the more explicit `gst_element_request_pad_simple()`.
See also https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/-/merge_requests/743#note_886586
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/802>
The peeked buffer was always reset after calling ::aggregate() but under
no other circumstances. If a pad was removed after peeking and before
::aggregate() returned then the peeked buffer would be leaked.
This can easily happen if pads are removed from the aggregator from a
pad probe downstream of the source pad but still in the source pad's
streaming thread.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/784>
When parsing interlaced video streams, ignoring incoming DTS could
cause the parser to end up with PTS < DTS output buffers, for example
when increasing next_dts using the duration of the last pushed
buffer.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/681>
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/677>
e.g. h264parse ! video/x-h264,stream-format=avc receives the following:
- caps: video/x-raw,stream-format=byte-stream
- gap event: baseparse tries to choose some default caps but would
override the downstream chosen caps field with upstreams value.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/581>
Some base classes like videoaggregator try retrieving the latency during
construction, which causes the latency values to be set already until
reconfiguration happens.
By resetting them the same way as in stop() we ensure that we always
start cleanly.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/599>
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/601>
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>
