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>
Add a new property so that clocksync can setup "ts-offset" value
based on the first buffer and pipeline's running time when the
first arrived. Newly update "ts-offset" in this case would be
a value that allows outputting the first buffer without clock waiting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/702>
This test takes 39 seconds on my machine even though it just runs
a couple of fakesrc num-buffers=2 ! fakesink pipelines. Most of
the cpu seems to be spent in libz, related to stack trace management.
Use stack-traces-flags=none instead of stack-traces-flags=full
until a better solution can be found. Might warrant more
investigation in any case..
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/503>
This is a follow up to review comments in !297
+ The posting of the buffering message in READY_TO_PAUSED isn't
needed, removing it made the test fail, but the correct fix
was simply to link elements together
+ Move code to relock the queue and set last_posted_buffering_percent
and percent_changed inside the buffering_post_lock in create_write().
This makes locking consistent with post_buffering()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
This fixes a bug that occurs when an attempt is made to post a buffering
message before the queue2 was assigned a bus. One common situation where
this happens is when the use-buffering property is set to TRUE before the
queue2 was added to a bin.
If the result of gst_element_post_message() is not checked, and the
aforementioned situation occurs, then last_posted_buffering_percent and
percent_changed will still be updated, as if posting the message succeeded.
Later attempts to post again will not do anything because the code then
assumes that a message with the same percentage was previously posted
successfully and posting again is redundant.
Updating these variables only if posting succeed and explicitely
posting a buffering message in the READY->PAUSED state change ensure that
a buffering message is posted as early as possible.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/297>
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.
The clocksync element is a generic element that can be
placed in a pipeline to synchronise passing buffers to the
clock at that point. This is similar to 'identity sync=true',
but because it isn't GstBaseTransform-based, it can process
GstBufferLists without breaking them into separate GstBuffers
Needs a valgrind suppression for:
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Warning: invalid file descriptor -1 in syscall close()
==11119== Syscall param write(buf) points to uninitialised byte(s)
==11119== at 0x4C4AFAD: syscall (in /usr/lib64/libc-2.29.so)
==11119== by 0x4E70DF9: write_validate (Ginit.c:112)
==11119== by 0x4E70DF9: UnknownInlinedFun (Ginit.c:148)
==11119== by 0x4E70DF9: mincore_validate (Ginit.c:131)
==11119== by 0x4E70CC3: UnknownInlinedFun (Ginit.c:208)
==11119== by 0x4E70CC3: access_mem (Ginit.c:242)
==11119== by 0x4E75536: UnknownInlinedFun (libunwind_i.h:168)
==11119== by 0x4E75536: apply_reg_state (Gparser.c:863)
==11119== by 0x4E75A71: _ULx86_64_dwarf_step (Gparser.c:952)
==11119== by 0x4E71BD3: _ULx86_64_step (Gstep.c:71)
==11119== by 0x48BAF47: generate_unwind_trace (gstinfo.c:2726)
==11119== by 0x48BC92E: gst_debug_get_stack_trace (gstinfo.c:2908)
==11119== by 0x49B2BB2: handle_object_created.part.0 (gstleaks.c:384)
==11119== by 0x488134E: gst_object_constructed (gstobject.c:141)
==11119== by 0x49EC61B: g_object_new_internal (gobject.c:1845)
==11119== by 0x49EE347: g_object_new_valist (gobject.c:2128)
==11119== by 0x49EE69C: g_object_new (gobject.c:1648)
==11119== by 0x48CA59D: gst_pad_new_from_template (gstpad.c:867)
==11119== by 0x68C209E: gst_base_src_init (gstbasesrc.c:454)
==11119== by 0x4A0A0C3: g_type_create_instance (gtype.c:1858)
==11119== by 0x49EC42C: g_object_new_internal (gobject.c:1805)
==11119== by 0x49EDB14: g_object_new_with_properties (gobject.c:1973)
==11119== by 0x49EE6C0: g_object_new (gobject.c:1645)
==11119== by 0x48AF91A: gst_element_factory_create (gstelementfactory.c:372)
==11119== Address 0x1ffeffe000 is on thread 1's stack
==11119== in frame #6, created by generate_unwind_trace (gstinfo.c:2695)
Fixed in libunwind commit:
b256722d49
Needs a separate suppression for Debian because the callstack is
different there.
This means we can use some newer features and get rid of some
boilerplate code using the `G_DECLARE_*` macros.
As discussed on IRC, 2.44 is old enough by now to start depending on it.
Allows determining from downstream what the expected bitrate of a stream
may be which is useful in queue2 for setting time based limits when
upstream does not provide timing information.
Implement bitrate query handling in queue2
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/60
Otherwise it's not guaranteed that buffers are actually on disk after
pushing them, and reading the file via g_file_get_contents() might not
include them yet.
The queue gets filled by the tail, so a query will always be the tail
object, not the head object. Also add a _peek_tail_struct() method to the
GstQueueArray to enable looking at the tail.
With unit test to prevent future regression.
https://bugzilla.gnome.org/show_bug.cgi?id=762875
Set up all ten pipelines and preroll them first, and only set
them to playing to run wild after they're all set up. If we set
them to PLAYING directly and let those threads run wild, then
it might take ages (many seconds) for the other pipelines to
even get up and running, especially on machines with only one
or two cores, and operating systems that suck at scheduling.
Now the fakesink test takes 19 secs instead of 71 secs on a
single-cpu windows machine.
The real use case is when downstream didn't set a pool or
allocation params, in which case we expect the tee to not
create a pool or param from thin air. Dowstream setting
an pool with size=0 was in fact testing a downstream element
bug. The fact we handle that is accidental.
If the aggregated size is 0 and we create a pool, the pool would provide
buffers with no memory assigned. Handle that case and skip the pool.
This was the behaviour before cf803ea9f4.
Add a test for this scenario.
https://bugzilla.gnome.org/show_bug.cgi?id=730758
In the unit test refactoring, the unlinked pad required to test
the different behaviour induced by "allow-not-linked" property
was removed.
Commit e364d7944e
Move all the code for this test in the proper function, and re-add
the missing unlinked pad. This makes the test useful again.
Split the large allocation_query test into seperate tests. Add a setup helper
to reduce code duplication. Fix the original test that used fail_unless instead
of ck_assert_int_eq and had it accidentially working.
This carries over code for a similar test from multiqueue to ensure full
control over the dataflow while testing. (The previous attempt was racy
since the fill level changed without any thread sync with the test code.)
https://bugzilla.gnome.org/show_bug.cgi?id=771210
low/high-watermark are of type double, and given in range 0.0-1.0. This
makes it possible to set low/high watermarks with greater resolution,
which is useful with large multiqueue max sizes and watermarks like 0.5%.
Also adding a test to check the fill and watermark level behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=770628
low/high-watermark are of type double, and given in range 0.0-1.0. This
makes it possible to set low/high watermarks with greater resolution,
which is useful with large queue2 max sizes and watermarks like 0.5%.
Also adding a test to check the fill and watermark level behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=769449
gst_check_setup_sink_pad() internally uses gst_check_chain_func() so we
should call gst_check_drop_buffers() when tearing down tests to free the
buffers which have been exchanged through the pipeline.
https://bugzilla.gnome.org/show_bug.cgi?id=765903
This ensures the following special case is handled properly:
1. Queue is empty
2. Data is pushed, fill level is below the current high-threshold
3. high-threshold is set to a level that is below the current fill level
Since mq->percent wasn't being recalculated in step #3 properly, this
caused the multiqueue to switch off its buffering state when new data is
pushed in, and never post a 100% buffering message. The application will
have received a <100% buffering message from step #2, but will never see
100%.
Fix this by recalculating the current fill level percentage during
high-threshold property changes in the same manner as it is done when
use-buffering is modified.
https://bugzilla.gnome.org/show_bug.cgi?id=763757
