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/647>
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/645>
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/643>
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/642>
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/634>
When posting a buffering message succesfully:
* Remember the *actual* percentage value that was posted
* Make sure we only reset the percent_changed variable if the value we just
posted is indeed different from the current value
Part-of: <https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/632>
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>
When running in pull mode (for e.g. mp3 reading),
baseparse currently reads 64KB from upstream, then mp3parse
consumes typically around 417/418 bytes of it. Then
on the next loop, it will read a full fresh 64KB again,
which is a big waste.
Fix the read loop to use the available cache buffer first
before going for more data, until the cache drops to < 1KB.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/518
In case the buffer is not writable, the parent (the BufferList) is not
removed before calling func. So if it is changed, the parent (the BufferList)
of the previous buffer should be removed after calling func.
Previously we would use the object lock only for storing the sync
handler and its user_data in a local variable, then unlock it and only
then call the sync handler. Between unlocking and calling the sync
handler it might be unset and the user_data be freed, causing it to be
called with a freed pointer.
To prevent this add a refcounting wrapper struct around the sync
handler, hold the object lock while retrieving it and increasing the
reference count and only actually free it once the reference count
reaches zero.
As a side-effect we can now also allow to actually replace the sync
handler. Previously it was only allowed to clear it after initially
setting it according to the docs, but the code still allowed to clear it
and then set a different one.
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/506
After release bison 2.5 the declaration %pure-parser was deprecated
in favor of %define api.pure
Nonetheless, until bison 3.4, the declaration was treated as backward
compatibility, but now bison shows a warning:
warning: deprecated directive, use ‘%define api.pure’
The patch's approach is to handle both directives according with the
used bison's version, by string replacement at source configuration
stage.
This reverts a96002bb28, which is not
necessary anymore. If we release the pad after removing it then none of
the deactivation code will actually be called because the pad has no
parent anymore, and we require a parent on the pad for deactivation to
happen.
This can then, among other things, cause a streaming thread to be still
stuck in a pad probe because the pad was never flushed, and waiting
there forever because now the pad will actually never be flushed anymore.
If a pad is currently being released we don't want to forward the
FLUSHING flow return but instead consider it as NOT_LINKED. FLUSHING
would also cause upstream to be FLUSHING.
This part was missed in a3c4a3201a and
resulted in a different (and wrong) workaround in
a96002bb28.
Otherwise we're not guaranteed to read the very latest value that
another thread might've written in there when the pad was released, and
could instead work with an old value.
The argument must be at least a GObject according to the GstLogFunction
definition, and while the default C log function handles miniobjects
just fine this is crashing bindings and user-supplied log functions that
(rightfully) don't expect anything but GObjects.
Concurrent Windows' colored debug message and g_print will print
string hard to read. Instead, use gst_print* which serialize
debug output and the APIs call.
On Windows, concurrent colored gstreamr debug output and usual
stdout/stderr string will cause broken output on terminal.
Since it's OS specific behavior, that's hard to completely avoid it
but we can protect it at least among our printing interfaces side.
