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
This new API allow resuming a task if it was paused, while leaving it to
stopped stated if it was stopped or not started yet. This new API can be
useful for callback driver workflow, where you basically want to pause and
resume the task when buffers are notified while avoiding the race with a
gst_task_stop() coming from another thread.
The old code would leave a dangling pointer in oldstr_ptr if two threads
attempted to take the same structure into the same location at the same
time:
1. First "oldstr == newstr" check (before the loop) fails.
2. Compare-and-exchange fails, due to a second thread completing the
same gst_structure_take.
3. Second "oldstr == newstr" check (in the loop) succeeds, loop breaks.
4. "oldstr" check succeeds, old structure gets freed.
5. oldstr_ptr now contains a dangling pointer.
This shouldn't happen in code that handles ownership sanely, so check
that we don't try to do this and complain loudly.
Also simplify the function by using a do-while loop, like
gst_mini_object_take.
https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/413
