Custom meta is backed by a GstStructure, and does not require
that users of the API expose their GstMeta implementation as
public API for other components to make use of it.
In addition, it provides a simpler interface by ignoring the
impl vs. api distinction that the regular API exposes.
This new API is meant to be the meta counterpart to custom events
and messages, and to be more convenient than the lower-level API
when the absolute best performance isn't a requirement.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/609>
Subsequent lookups in the hashtable are probably better done
on memory we're confident is allocated to us :)
It was easy to trigger invalid reads by calling gst_meta_register
with dynamically allocated memory, freeing that memory, then
calling gst_meta_get_info()
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/628>
663: Warning: Gst: symbol='GFLOAT_TO_LE': Unknown namespace for symbol 'GFLOAT_TO_LE'
664: Warning: Gst: symbol='GFLOAT_TO_BE': Unknown namespace for symbol 'GFLOAT_TO_BE'
665: Warning: Gst: symbol='GDOUBLE_TO_LE': Unknown namespace for symbol 'GDOUBLE_TO_LE'
666: Warning: Gst: symbol='GDOUBLE_TO_BE': Unknown namespace for symbol 'GDOUBLE_TO_BE'
669: Warning: Gst: symbol='GFLOAT_TO_LE': Unknown namespace for symbol 'GFLOAT_TO_LE'
670: Warning: Gst: symbol='GFLOAT_TO_BE': Unknown namespace for symbol 'GFLOAT_TO_BE'
671: Warning: Gst: symbol='GDOUBLE_TO_LE': Unknown namespace for symbol 'GDOUBLE_TO_LE'
672: Warning: Gst: symbol='GDOUBLE_TO_BE': Unknown namespace for symbol 'GDOUBLE_TO_BE'
678: Warning: Gst: symbol='GFLOAT_FROM_LE': Unknown namespace for symbol 'GFLOAT_FROM_LE'
679: Warning: Gst: symbol='GFLOAT_FROM_BE': Unknown namespace for symbol 'GFLOAT_FROM_BE'
680: Warning: Gst: symbol='GDOUBLE_FROM_LE': Unknown namespace for symbol 'GDOUBLE_FROM_LE'
681: Warning: Gst: symbol='GDOUBLE_FROM_BE': Unknown namespace for symbol 'GDOUBLE_FROM_BE'
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
Easier to just make g-ir-scanner skip this header via #ifndef __GI_SCANNER__
than maintain different sets of headers in the meson.build file.
Warning: Gst: symbol="rint": Unknown namespace for symbol "rint"
Warning: Gst: symbol="rintf": Unknown namespace for symbol "rintf"
Warning: Gst: symbol="isnan": Unknown namespace for symbol "isnan"
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
gstevent.h:72: Warning: Gst: symbol='FLAG': Unknown namespace for symbol 'FLAG'
gstquery.h:76: Warning: Gst: symbol='FLAG': Unknown namespace for symbol 'FLAG'
Use _FLAG(xyz) instead of FLAG(xyz) to silence g-ir-scanner
warnings about this internal helper define.
It's also slightly more hygienic.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/579>
It's been around for more than 4 years and people have built
lots of stuff on top of it, doesn't really make sense to keep
it marked as unstable. We're unlikely to change it now, and
we can always deprecate it and make a new one if needed.
This stabilises the following API:
- gst_tracer_register()
- gst_tracing_get_active_tracers()
- gst_tracing_register_hook()
- gst_tracer_record_new()
- gst_tracer_record_log()
Might also help a bit with #424
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/576>
The global seqnum variable wasn't actually increased in
the fallback code path, leading to all buffers getting
a seqnum of 0. Which also made the unit test fail.
This affects platforms/toolchains that don't have
64-bit atomic ops such as when compiling for armv7 rpi.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/565>
For providers that don't support dynamic probing, just fall back to doing
a static one on start() to make the UI developers life easier.
This also means that the monitor doesn't need to call _can_monitor() before
calling start.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/353>
In case a plugin filename was renamed with the plugin being in the registry cache
the features were not loaded after the rename:
1) Cache of old/gone filename was loaded, features added
2) New filename was loaded, features where not added because
they were already found in the registry.
3) In the end stale cache entries for files which are no longer there
are removed, including the wanted features.
4) The cache gets updated without the features.
Fix this by also checking at (2) that the found feature is from the loaded plugin
and not from some stale cache entry.
This affected directsoundsink where libgstdirectsoundsink.dll was renamed
to libgstdirectsound.dll, losing the directsoundsink element in the process.
Fixes#290
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/102>
Otherwise the proxy pad of the ghost pad still stays linked to some
element inside the bin, which is not allowed anymore according to the
topology.
In 2.0 this should be fixed more generically from inside GstGhostPad but
currently there is no way to get notified that the ghost pad is
unparented.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/553>
There is a race-condition that can trigger the assertion in
gst_bus_add_signal_watch_full():
If gst_bus_add_signal_watch_full() is called immediately after
gst_bus_remove_signal_watch() then bus->priv->signal_watch may still be set
because gst_bus_source_dispose() or gst_bus_source_finalize() was not yet
called.
This happens if the corresponding GMainContext has the source queued for
dispatch. In this case, the following dispatch will only unref and delete
the signal_watch because it was already destroyed. Any pending messages
will remain until a new watch is installed.
So bus->priv->signal_watch can be cleared immediately when the watch is
removed. This avoid the race condition.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/543>
Instead do everything it did as part of GObject::constructed() and
change the function to always return TRUE.
gst_ghost_pad_construct() was meant to be called by subclasses right
after construction of the object to finish construction as it can fail
in theory. In practice it's impossible for it to fail, even more so if
called directly from GObject::constructed(): The only failure condition
is if the newly created proxy pad already has a parent, which is
impossible at this point as nothing else can have a reference to it.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/540>
Since glib 2.64, gthreadpool will start waiting on a GCond immediately upon
creation. This can cause issues if we fork *before* actually using the
threadpool since we will then be signalling that GCond ... from another process
and that will never work.
Instead, delay creationg of thread pools until the very first time we need
them. This introduces a minor (un-noticeable) delay when needing a new thread
but fixes the issues for all users of GSTreamer that will call gst_init, then
fork and actually start pipelines.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2131 for more context.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/531>
When compiling for 32bit ios arm, the static assert that the
GstClockEntryImpl smaller or equal to the struct _GstClockEntryImpl
triggered. (they were 12bytes off).
To fix this, the padding is increased by 12 bytes (on 32bit).
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/525>
These can be passed to gst_type_mark_as_plugin_api, to inform
plugin cache generation.
For now a single flag is specified, "IGNORE_ENUM_MEMBERS", it
can be used for dynamically generated enums to avoid documenting
environment-specific enumeration members. An example is
GstX265EncTune.
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
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
