...instead of a file descriptor so buffered I/O is used when writing
the binary cache. This boosts performance at startup, particularly on
network filesystems where writes may be quite slow.
Fixes gstreamer#545.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/458>
For value types that aren't subclassable, just check the type directly.
For flags, compare against the fundamental type directly instead of going through
the more expensive recursive check of `G_TYPE_CHECK_VALUE_TYPE()`
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/453>
The problem is that:
* g_value_init will end up allocating an internal list/array
* g_value_copy *clears* the existing value by calling the free func
and then the copy function (creating it again)
To avoid that alloc/free/alloc cycle, directly call the appropriate
function
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/453>
Previously this was:
* iterating and referencing all plugin features in a GList
* *then* filtering out the ones we want
* Was doing that filtering by name (i.e. `strcmp`) instead of direct pointer
comparision
Instead, just create a private direct function to get the list of plugin
features
Uses 4 times less instructions ...
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/462>
The intersection function table is a legacy of 2005, when one could
register random intersection functions. This is no longer the case.
The only place where that table was used was:
* `gst_value_can_intersect()`, where it was already only used for identical
GType
* `gst_value_intersect()`, where the table iteration was insanely expensive
Instead this patch:
* Only stored intersection functions for *different* types (of which there are
only 4)
* Make gst_value_intersect directly call the same-type intersection functions
and only use the table if ever it doesn't match.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/454>
This was going through a few locks and doing temporarily allocations for every
single task creation.. just to get a name.
We don't need to take locks since:
* The parent exists (we have a reference to it)
* The pad exists (the task belongs to it)
* Changing names of pad/elements when activating is a big no-no
Instead use the existing direct GST_DEBUG_PAD_NAME macro
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/455>
In static linking scenarios, this is required to avoid this error
building tests:
/work/prefix/lib/libgstcheck-1.0.a(check_run.c.o): In function `tcase_run_tfun_fork':
/work/gstreamer/_builddir/../../../src/gstreamer/libs/gst/check/libcheck/check_run.c:476: undefined reference to `timer_create'
/work/gstreamer/_builddir/../../../src/gstreamer/libs/gst/check/libcheck/check_run.c:483: undefined reference to `timer_settime'
/work/gstreamer/_builddir/../../../src/gstreamer/libs/gst/check/libcheck/check_run.c:493: undefined reference to `timer_delete'
/work/prefix/lib/libgstcheck-1.0.a(check.c.o): In function `check_get_clockid':
/work/gstreamer/_builddir/../../../src/gstreamer/libs/gst/check/libcheck/check.c:628: undefined reference to `timer_create'
/work/gstreamer/_builddir/../../../src/gstreamer/libs/gst/check/libcheck/check.c:629: undefined reference to `timer_delete'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/447>
This reverts commit cd751c2de3.
Reverts https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/406
Fixes glviewconvert negotiation in e.g.:
gltestsrc ! glviewconvert output-mode-override=side-by-side ! glstereosplit name=s s.left ! queue ! fakesink s.right ! queue ! glimagesink
Problem here is that intersecting flagsets in gst_value_intersect will
always find a value comparison function but may fail a direct type
comparison due to flagsets supporting derived types. When flagset
derived types are intersected, an intersection will therefore always
fail.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/441>
If this is not done, tools like xdot fail with "unexpected char
b'\\'". This is a regression caused by commit
74938f07c2 (multiqueue: Add stats
property).
The deserialized value coming out of g_object_get_property looks like
this,
$24 = (gchar *) 0x7f560c0046a0 "application/x-gst-multi-queue-stats, queues=(structure)< \\\"queue_0\\\\,\\\\ buffers\\\\=\\\\(uint\\\\)39\\\\,\\\\ bytes\\\\=\\\\(uint\\\\)8
120251\\\\,\\\\ time\\\\=\\\\(guint64\\\\)1460000000\\\\;\\\", \\\"queue_1\\\\,\\\\ buffers\\\\=\\\\(uint\\\\)186\\\\,\\\\ bytes\\\\=\\\\(uint\\\\)838020\\\\,\\\\ time\\\\=\
\\\(guint64\\\\)1984000002\\\\;\\\" >;"
That is immediately looking wrong. I don't know enough about GNOME
serialization details to say with confidence what happened here. It
gets worse after this is sent through g_strescape and then written to
the dot file. Interestingly, dot -Tpng is fine to ignore them it
seems.
Since the stats are by definition verbose, I decided the best choice
to omit them from the dot file, since such details are not of interest
there.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/442>
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.
downloadbuffer source pad pushes the first buffer before pushing
Stream Start and Segment event, when working in Push mode.
Fix:Pushing Stream Start and Segment after coming out of
wait for data, and before pushing the buffer to next element.
Fixes#534
Since bash-completion 2.9, it was no longer possible to override
the completionsdir through prefix. [1] In 2.10, the overridability
was re-estabilished but this time through datadir variable. [2]
This should not really matter except for developers installing the project
into a custom prefix or distros using per-package prefixes like NixOS.
[1]: 81ba2c7e7d
[2]: https://github.com/scop/bash-completion/pull/344
There is not point waiting if the time to wait is less than this
platform specific value. The worst case here is GCond usage on windows
where the granularity is 1ms.
Problem:
multiple aggregator elements (audiomixer, compositor) in a live
pipeline use a lot of CPU waiting each other up. This is because
of the previously unused clock entry unscheduling during regular
operation.
Clock entry unscheduling has the potential to wake up every clock entry
waiting using the system clock which may be a large number.
Solution:
Implement waiting per entry and only wakeup the unscheduled entry.
While this may be possible using GCond, theoretically GCond only gives
us microsecond accuracy and uses relative waits in a number of places.
We can unfortunately do better poking at the platform specifics
ourselves by using futexes on linux and pthread on other unix. Windows
may have a possible implementation using Waitable timers but that is
not implemented here and instead falls back to the GCond implementation.
GCond waits on Windows is still as accurate as the previous GstPoll-based
implementation.
When a live pipeline goes to PLAYING, its change_state method
is called twice for PAUSED_TO_PLAYING: the first time is
from GstElement, when NO_PREROLL is returned, the second
is from GstBin, after all async_done messages have been
collected.
base_time selection is done only the first time, through
comparisons with start_time.
On the other hand, when this live pipeline gets flush seeked,
even though start_time is reset by the sink upon reception
of flush_stop(reset_time=TRUE), PAUSED_TO_PLAYING only occurs
once, from GstBin, after all async_done messages have been
collected. This causes the base_time to be off by <latency>.
This commit addresses this by mimicing the behaviour of
GstElement on NO_PREROLL, and calling the change_state
method manually when the following conditions are met:
* The pipeline is live
* The target state is PLAYING
The returned "stats" structure contains, for now, one array called
"queues" with one GstStructure per internal queue, containing said
queue's current level of bytes, buffers, and time.
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
It is not explicitly specified anywhere in the docs that 0% buffering is
at low-watermark and 100% buffering is at high-watermark. It was
specified only in the sources.
