This can be used to mark additional types exposed by plugins (i.e.
enums, flags and GObjects) via properties, signals or pad templates as
plugin API. They can then be picked up by the documentation for the
plugin.
Not all types exposed by plugins are documented automatically because
they might come from an external library and should be documented from
there instead.
Nowadays we are only waking up the head entry waiting if either the head
entry is unscheduled (which is handled some lines above already), or
when the head entry specifically is woken up because a new entry became
the new head entry.
We're not waking up *all* entries anymore whenever any entry in the last
was unscheduled.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
We already have a mutex in each clock entry anyway and need to make use
of that mutex in most cases when the status changes. Removal of the
atomic operations and usage of the mutex instead simplifies the code
considerably.
The only downside is that unscheduling a clock entry might block for the
time it needs for the waiting thread to go from checking the status of
the entry to actually waiting, which is not a lot of code.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
Otherwise it can happen that unscheduling a clock id never takes place
and instead it is waiting until the normal timeout. This can happen if
the wait thread checks the status and sets it to busy, then the
unschedule thread sets it to unscheduled and signals the condition
variable, and then the waiting thread starts waiting. As condition
variables don't have a state (unlike Windows event objects), we have to
remember ourselves in a new boolean flag protected by the entry mutex
whether it is currently signalled, and reset this after waiting.
Previously this was not a problem because a file descriptor was written
to for waking up, and the token was left on the file descriptor until
the read from it for waiting.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/500>
This was effectively disabled in 1.0 with the intent of maybe re-enabling it.
The problem is that caching duration at a bin level doesn't make much sense
since there might be queueing/buffering taking place internally and therefore
the duration reported might have no correlation to what is actually being
outputted.
Remove commented code and fixmes, and update documentation
Fixes#4
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/489>
We must not retry fclose() on EINTR as POSIX states:
After the call to fclose(), any use of stream results in undefined
behavior.
We ensure above with fflush() and fsync() that everything is written out
so chances of running into EINTR are very low. Nonetheless assume that
the file can't be safely renamed, we'll just try again on the next
opportunity.
CID #1462697
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/465>
...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>
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.
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
